VPNs Illustrated: Tunnels, VPNs, and IPsec

Next Page

Book Cover
VPNs Illustrated: Tunnels, VPNs, and IPsec
By Jon C. Snader
...............................................
Publisher: Addison Wesley Professional
Pub Date: October 26, 2005
ISBN: 0-321-24544-X
Pages: 480

Table of Contents | Index
Overview

Virtual private networks (VPNs) based on the Internet instead of the traditional leased lines offer organizations of all sizes the promise of a low-cost, secure electronic network. However, using the Internet to carry sensitive information can present serious privacy and security problems. By explaining how VPNs actually work, networking expert Jon Snader shows software engineers and network administrators how to use tunneling, authentication, and encryption to create safe, effective VPNs for any environment.

Using an example-driven approach, VPNs Illustrated explores how tunnels and VPNs function by observing their behavior "on the wire." By learning to read and interpret various network traces, such as those produced by tcpdump, readers will be able to better understand and troubleshoot VPN and network behavior.

Specific topics covered include:

  • Block and stream symmetric ciphers, such as AES and RC4; and asymmetric ciphers, such as RSA and EIGamal

  • Message authentication codes, including HMACs

  • Tunneling technologies based on gtunnel

  • SSL protocol for building network-to-network VPNs

  • SSH protocols as drop-in replacements for telnet, ftp, and the BSD r-commands

  • Lightweight VPNs, including VTun, CIPE, tinc, and OpenVPN

  • IPsec, including its Authentication Header (AH) protocol, Encapsulating Security Payload (ESP), and IKE (the key management protocol)

Packed with details, the text can be used as a handbook describing the functions of the protocols and the message formats that they use. Source code is available for download, and an appendix covers publicly available software that can be used to build tunnels and analyze traffic flow.

VPNs Illustrated gives you the knowledge of tunneling and VPN technology you need to understand existing VPN implementations and successfully create your own.

Next Page


Table of Contents

Previous Page

Book Cover
VPNs Illustrated: Tunnels, VPNs, and IPsec
By Jon C. Snader
...............................................
Publisher: Addison Wesley Professional
Pub Date: October 26, 2005
ISBN: 0-321-24544-X
Pages: 480

Table of Contents | Index

Copyright
Preface
 | Introduction
Source Code and Errata Availability
Colophon
Acknowledgments
Part 1: Background
 | Chapter 1. Introduction
 |  | Section 1.1. Purpose
 |  | Section 1.2. Readers
 |  | Section 1.3. Typographical Conventions
 |  | Section 1.4. Source Code and Third-Party Programs
 |  | Section 1.5. Testbed
 |  | Section 1.6. Road Map
 |  | Section 1.7. Summary
 | Chapter 2. TCP/IP Overview
 |  | Section 2.1. Introduction
 |  | Section 2.2. Layering
 |  | Section 2.3. Encapsulation
 |  | Section 2.4. Addressing
 |  | Section 2.5. IP
 |  | Section 2.6. UDP
 |  | Section 2.7. TCP
 |  | Section 2.8. ICMP
 |  | Section 2.9. NAT and Private IP Addresses
 |  | Section 2.10. PPP
 |  | Section 2.11. IPv6
 |  | Section 2.12. Routing
 |  | Section 2.13. Summary
 |  | Exercises
 | Chapter 3. Cryptography Overview
 |  | Section 3.1. Introduction
 |  | Section 3.2. Symmetric Ciphers
 |  | Section 3.3. Asymmetric Ciphers
 |  | Section 3.4. Cryptographic Hash Functions, MACs, and HMACs
 |  | Section 3.5. Digital Signatures
 |  | Section 3.6. Certificates
 |  | Section 3.7. Summary
 |  | Exercises
 | Chapter 4. Tunnels
 |  | Section 4.1. Introduction
 |  | Section 4.2. IP-in-IP Tunnels
 |  | Section 4.3. PPPoE
 |  | Section 4.4. GRE
 |  | Section 4.5. PPTP
 |  | Section 4.6. L2TP
 |  | Section 4.7. MPLS
 |  | Section 4.8. gtunnel
 |  | Section 4.9. Summary
 |  | Exercises
Part 2: Tunnels and VPNs
 | Chapter 5. Virtual Private Networks
 |  | Section 5.1. Introduction
 |  | Section 5.2. PPTP
 |  | Section 5.3. L2TP
 |  | Section 5.4. Other VPNs
 |  | Section 5.5. Summary
 |  | Exercises
 | Chapter 6. Secure Sockets Layer
 |  | Section 6.1. Introduction
 |  | Section 6.2. Cipher Suites
 |  | Section 6.3. The SSL Protocol
 |  | Section 6.4. SSL on the Wire
 |  | Section 6.5. OpenSSL
 |  | Section 6.6. The stunnel Program
 |  | Section 6.7. SSL Security
 |  | Section 6.8. Summary
 |  | Exercises
 | Chapter 7. SSH
 |  | Section 7.1. Introduction
 |  | Section 7.2. The SSHv1 Protocol
 |  | Section 7.3. The SSHv2 Protocol
 |  | Section 7.4. Building VPNs with SSH
 |  | Section 7.5. Summary
 |  | Exercises
 | Chapter 8. Lightweight VPNs
 |  | Section 8.1. Introduction
 |  | Section 8.2. VTun
 |  | Section 8.3. CIPE
 |  | Section 8.4. Tinc
 |  | Section 8.5. OpenVPN
 |  | Section 8.6. Summary
 |  | Exercises
Part 3: IPSec
 | Chapter 9. IPsec
 |  | Section 9.1. Introduction
 |  | Section 9.2. An Overview of IPsec
 |  | Section 9.3. Road Map for Part 3
 |  | Section 9.4. Summary
 |  | Exercises
 | Chapter 10. IPsec Architecture
 |  | Section 10.1. Introduction
 |  | Section 10.2. Protocols
 |  | Section 10.3. IPsec Modes
 |  | Section 10.4. Security Associations
 |  | Section 10.5. Combining Security Associations
 |  | Section 10.6. Policies
 |  | Section 10.7. IPsec Processing
 |  | Section 10.8. Summary
 |  | Exercises
 | Chapter 11. AH
 |  | Section 11.1. Introduction
 |  | Section 11.2. The AH Header
 |  | Section 11.3. Sequence Numbers
 |  | Section 11.4. AH Processing
 |  | Section 11.5. Transport Mode
 |  | Section 11.6. Tunnel Mode
 |  | Section 11.7. AH with IPv6
 |  | Section 11.8. Summary
 |  | Exercises
 | Chapter 12. ESP
 |  | Section 12.1. Introduction
 |  | Section 12.2. The ESP Header
 |  | Section 12.3. ESP Processing
 |  | Section 12.4. Transport Mode
 |  | Section 12.5. Tunnel Mode
 |  | Section 12.6. ESP with IPv6
 |  | Section 12.7. Summary
 |  | Exercises
 | Chapter 13. IKE
 |  | Section 13.1. Introduction
 |  | Section 13.2. ISAKMP
 |  | Section 13.3. IKE
 |  | Section 13.4. An Example Negotiation
 |  | Section 13.5. Summary
 |  | Exercises
 | Chapter 14. IPsec Futures
 |  | Section 14.1. Introduction
 |  | Section 14.2. IPsec Architecture
 |  | Section 14.3. AH
 |  | Section 14.4. ESP
 |  | Section 14.5. IKE
 |  | Section 14.6. NAT Traversal
 |  | Section 14.7. Summary
 |  | Exercises
 | Appendix A. Source Code
 |  | A.1 Introduction
 |  | A.2 Cryptographic Routines
 |  | A.3 Library Code
 | Appendix B. Miscellaneous Software
 |  | B.1 Netcat
 |  | B.2 tcpdump and Other Packet Sniffers
 |  | B.3 ssldump
 |  | B.4 PPP
Bibliography
Index

Previous Page


Copyright

Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact:

U.S. Corporate and Government Sales
(800) 382-3419
corpsales@pearsontechgroup.com

For sales outside the U.S., please contact:

International Sales
international@pearsoned.com

Visit us on the Web: www.awprofessional.com

Library of Congress Cataloging-in-Publication Data
Snader, Jon C., 1944
VPNs illustrated : tunnels, VPNs, and IPsec / Jon C. Snader.
p. cm.
Includes bibliographical references and index.
ISBN 0-321-24544-X (pbk. : alk. paper)
1. Extranets (Computer networks) 2. IPSec (Computer network protocol)
I. Title: Tunnels, VPNs, and IPsec. II. Title.

TK5105.875.E87S53 2005
004.67'8dc22
2005023223

Copyright © 2006 Pearson Education, Inc.

All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to:

Pearson Education, Inc.
Rights and Contracts Department
One Lake Street
Upper Saddle River, NJ 07458

Text printed in the United States on recycled paper at R.R. Donnelley in Crawfordsville, Indiana.

First printing, October 2005

Dedication

To Rich Stevens, who showed me the way, and to Maria, who makes it all possible.


Preface

    Introduction


Introduction

There is a revolution going on in enterprise networking. Until very recently, enterprises that needed to link computers in geographically dispersed locations had to build their own wide area networks (WANs). Usually this meant renting expensive and, by today's Internet standard, relatively slow frame relay circuits. A typical 56 Kb/s circuit could cost several hundred, or even over a thousand, dollars a month.

Today, the typical home computer user enjoys a broadband Internet connection having a 5 Mb/s download speed for a cost of about $40 per month. Commercial variants of this service, offering higher speeds and other amenities, are available for between $100 and $200 per month. Obviously, this significant increase in speed and decrease in cost represent a tremendous opportunity for enterprises, but they do introduce new problems.

The Internet is an open environment and, compared to leased lines, dreadfully insecure. Increases in bandwidth and decreases in cost are worthless if they mean that an enterprise's vital data can be intercepted by competitors, or that financial transactions are subject to manipulation by outsiders. This book discusses ways to overcome these problems by recreating the security of leased lines in a public medium such as the Internet.

The fundamental mechanism that allows us to have secure communications in the Internet is the notion of a tunnel. As we'll see, tunnels are a way of overlaying a logical or virtual network on top of a physical network. Once we have such a tunnel, we can secure it by encrypting and authenticating the network traffic that flows through it, thus recreating the security of private leased lines.

Of course, this simple description hides a substantial set of details and problems. We'll see that it's actually quite difficult to endow such tunnels with robust security. Much of the book is concerned with exploring solutions to these problems, and seeing why the successful solutions work and where the unsuccessful ones fail.


Source Code and Errata Availability

Source code discussed in the text and other supporting material are available on my Web site at <http://home.netcom.com/~jsnader>. The networking libraries and skeletons from Effective TCP/IP Programming, which I mention and use occasionally in the text, are also available on the Web site.

My readers, it turns out, are much better at finding mistakes than I am. Although I go over the text carefully, checking that every i is dotted and every t crossed, errors still manage to evade me. Fortunately, most of these are caught by the careful and fastidious professionals at Addison-Wesley. Still, some errors will no doubt escape into the final published text. As these are discoveredusually by careful readersI add them to an errata list for the book. This list is always available at my Web site.


Colophon

As with my previous book, I produced camera-ready copy for this text using James Clark's splendid Groff typesetting suite (now maintained by Ted Harding and Werner Lemberg) and Rich Stevens' modified ms macros. I used the gpic, gtbl, and geqn preprocessors for the figures, tables, and mathematical notation, respectively. Some of the figures use gpic macros from Rich Stevens and Gary Wright. Indexing tools from Jon Bentley and Brian Kernighan were a huge help in the production of the index. I included the source code for the programming examples directly from their source files with Dave Hanson's loom utility. The text is set in the Palatino typeface.


Acknowledgments

Although writing a book is primarily a solitary endeavor, it is nevertheless true that many people make many kinds of contributions to the effort, and that without those contributions, most books, including this one, would not see the light of day. Once again, I have to thank my wife, Maria, who inexplicably agreed to sign on for another book. Considering the extra work and lonely hours that this entails, it's a considerable sacrifice, and one for which there are no words adequate to thank her.

Several reviewers suffered through drafts at various stages in the writing cycle. Ronan McLaughlin, Thomas D. Nadeau, and Radia Perlman reviewed some early material from the proposal stage and offered much good advice. Radia Perlman also reviewed some of the earlier chapters. Peter Gutmann and Sandra Henry-Stocker read and reviewed the entire manuscript. Their advice and technical insights were a tremendous help to me in writing the book. Finally, Robin Snader was the first to read much of the material, and he provided valuable and detailed feedback that helped shape the form and content of the book. All these reviewers provided invaluable assistance and helped make the book much better than it otherwise would have been. I offer them my heartfelt thanks.

No acknowledgments would be complete without mentioning the wonderful staff at Addison-Wesley. Mary Franz helped get the project started and championed the book to Addison-Wesley. My editor, Catherine Nolan, brought her prodigious editing and library science skills to bear and helped shaped the book into its final form. She also taught me a lot of things I didn't know about bibliographies; who knew there was so much to learn? Evelyn Pyle copyedited the book in astounding detail. Her careful checking of every cross reference and citation caught many errors, and left me wondering whether she knew more about the subject matter than I do. Linda Begley, whose sharp eyes would make an eagle weep with envy, proofread the final pages. My production editor, Tyrrell Albaugh, once again helped one of my books through the difficult birthing process. Her cheerful prodding to "do the right thing" helped make the book better in every way.

In view of Rich Stevens' extraordinary TCP/IP Illustrated series [Stevens 1994, Wright and Stevens 1995, Stevens 1996], naming this book VPNs Illustrated might be considered an act of hubris, but my intent is merely to pay homage to Rich and his books. Those books are at once the benchmark and goal towards which I strive in my own writing.

As always, I welcome readers' comments, suggestions, and corrections. Please feel free to email me at the address below.

Tampa, Florida
October 2005

Jon C. Snader
jsnader@ix.netcom.com
http://home.netcom.com/~jsnader


Part 1: Background

    Chapter 1. Introduction

    Chapter 2. TCP/IP Overview

    Chapter 3. Cryptography Overview

    Chapter 4. Tunnels


Chapter 1. Introduction

    Section 1.1. Purpose

    Section 1.2. Readers

    Section 1.3. Typographical Conventions

    Section 1.4. Source Code and Third-Party Programs

    Section 1.5. Testbed

    Section 1.6. Road Map

    Section 1.7. Summary


Section 1.1. Purpose

1.1. Purpose

This book focuses on the technology behind tunneling and virtual private networks (VPNs). The explosive growth of the Internet and the buildout of the underlying infrastructure have led many enterprises to replace their private networks based on leased lines with far cheaper solutions based on the public Internet. Although the cost savings are substantial, using the Internet to carry sensitive information presents serious privacy and security problems. One way of addressing these problems is to create private, virtual networks within the Internet structure. These virtual networks are created by using tunneling, authentication, and encryption to provide a virtual leased line between enterprise networks. Because the traffic flow is encrypted and authenticated, it cannot be read or tampered with by third parties, and thus the virtual network recreates the privacy and security of a leased line.

The book is intended for software engineers, systems/sales engineers, system administrators, and others who want an in-depth understanding of tunneling and VPN technology. The text provides the background necessary for readers to understand existing VPN implementations, to create their own implementations, and to read the field's advanced literature in an informed way. The text also teaches readers how to read and interpret various network traces, such as those produced by tcpdump, as a way of understanding and troubleshooting VPN and network behavior. Finally, the text can be used as a handbook for those seeking information about the functioning of the protocols that we discuss or the message formats that they use.

Our intent is not to restate the relevant RFCs (Request for Comments) or provide an abstract discussion of tunnels and VPNs, but rather to explore how tunnels and VPNs actually function, by observing their behavior "on the wire." This is accomplished by examining network traces that expose the behavior and packet content of the protocols used in building tunnels and VPNs. This is, of course, the same approach used in Rich Stevens' wonderful TCP/IP Illustrated, Volume 1 [Stevens 1994].


Section 1.2. Readers

1.2. Readers

This book is aimed primarily at developers, system engineers, and IT personnel who need to understand tunneling and VPN technology. Readers should have a basic understanding of networking concepts and feel comfortable with such chores as configuring interfaces and routing on their workstations. Chapter 2 provides a brief review of the TCP/IP suite, including packet and header formats.

Cryptography plays a central role in VPN technology. Chapter 3 covers the basics of cryptography at a level more than adequate to understand its use in the text. Modern cryptography is based on mathematical ideas, some of which are quite sophisticated. Nonetheless, only very modest mathematical skills, mostly some facts about modular arithmetic, are needed to understand the cryptographic ideas in the text. Even so, readers can skip over the mathematics without losing anything critical.

In a few places, the text presents some example code. Readers with a basic understanding of C will have no problems with the C code or even the examples in Python. The code serves only to illustrate various points in the book, and no real programming skills are needed. Readers unfamiliar with C or Python but with experience in another language should be able to follow most of the code from the detailed discussions that accompany it. Readers unfamiliar with any programming language can still follow the important ideas by reading the commentary that accompanies the code.


Section 1.3. Typographical Conventions

1.3. Typographical Conventions

During our explorations we will run many small examples designed to illustrate some aspect of the protocol we are examining. When we show interactive input and output, we will use the following conventions:

  • User input is set in boldface monospaced type.

  • System output is set in plain monospaced type.

  • Comments that are not part of the input or output are set in italics:

    laptop# ifconfig gif0 create

    laptop# ifconfig gif0 192.168.0.2 192.168.0.1 logical addresses

    laptop# gifconfig gif0 172.30.0.12 172.30.0.1 physical addresses

  • The name of the system is included in the shell prompt

  • Some material is set off from the surrounding text.

    Footnote-type material and parenthetical remarks are set in smaller type and are indented like this paragraph. Often, this material can be skipped on a first reading.

  • URLs are set off with angle brackets.

    <http://www.freebsd.org>


Section 1.4. Source Code and Third-Party Programs

1.4. Source Code and Third-Party Programs

The limited amount of programming code in the book is, for the most part, self-contained. It is written in either standard C or Python. Readers familiar with C but not Python should have no problem understanding the Python examples. All the code from the text is available from the author's Web site.

Some of the programming examples make use of a networking library developed for the author's previous book Effective TCP/IP Programming [Snader 2000]. The functions in the library are described in Appendix A; the code is available from the author's Web site.

In some instances we will use publicly available programs to help illustrate a point, build a tunnel, or analyze traffic flow. Appendix B describes these programs and provides a pointer to where they can be obtained.

Occasionally we'll mention Effective TCP/IP Programming in the text. When we do, we'll refer to it as ETCP.


Section 1.5. Testbed

1.5. Testbed

Throughout the text we will use the test network shown in Figure 1.1 to perform tests and to demonstrate the operation of the various tunnels and VPNs that we study.

Figure 1.1. The Test Network

[View full size image]

The bsd and laptop hosts run FreeBSD 4.10, the linux and linuxlt hosts run Linux 2.4, and the Solaris host runs Solaris 8 on Intel.

The laptop and linuxlt hosts are shown as dashed because they're both laptops that are plugged into various places on the network as required by the situation. When we discuss a particular example, we will include only the parts of the network that are pertinent to that example.

Although each of these hosts runs some version of UNIX, this book is not about UNIX networking. We are interested in the protocols themselves, not in any particular implementation, so the hosts on which the examples and tests are run is immaterial.


Section 1.6. Road Map

1.6. Road Map

The book comprises three parts: background material (Part 1), a discussion of tunneling and VPN technology (Part 2), and a discussion of IPsec (Part 3). Each part depends to some extent on the material in previous parts, but readers with the appropriate background can read them independently. In particular, readers who are interested only in IPsec can skip directly to Part 3, and use the other two parts to fill in any gaps in their backgrounds as needed.

Background Material

Part 1 provides background material that allows the text to be mostly self-contained. Chapter 2 is a review of the core TCP/IP protocols. It pays particular attention to the notion of encapsulation, an idea that is a central concept in the text. The chapter also has brief discussions of NAT, PPP, and routing.

Chapter 3 is a primer on basic modern cryptography. This chapter covers block and stream symmetric ciphers, such as DES, 3DES, AES, and RC4, and the asymmetric ciphers, such as RSA and ElGamal, which form the basis for public key cryptography.

Next, the chapter discusses message authentication codes, a sort of cryptographic checksum, that can detect tampering with a message by a third party. Particular attention is paid to the class of authentication codes called HMACs.

Finally, the chapter briefly discusses digital signatures and certificates. These ideas play an important role in many of the authentication protocols that we will study.

Chapter 4 focuses on tunnels and tunneling technology. After defining a tunnel as a way of providing a virtual network on top of a real network through encapsulation, the chapter discusses several examples of tunnels and how they are used to solve various networking problems. These tunnels are explored in depth; the chapter examines both their message formats and their on-the-wire behavior.

The chapter concludes with a discussion of gtunnel, a generalized mechanism that allows users to build tunnels with a user-space program. Several VPN technologies use the ideas in gtunnel to build their tunnels.

Tunnels and VPNs

Part 2 focuses on using the tunneling technology from Chapter 4 to build VPNS. Chapter 5 reexamines two of the tunnels from Chapter 4 and observes how encryption is added to the tunnels to make rudimentary VPNs.

Chapter 6 studies the SSL protocol and how it can provide a VPNor at least VPN-like functionalityat the application layer. Although some authorities object to calling SSL a tunneling or VPN technology, we'll see that it can, in fact, be used to build real network-to-network VPNs. Later chapters discuss how the SSL protocol is used in some VPN technologies to provide end-node authentication and key-management functions.

Chapter 7 discusses the two SSH protocols and how they are used as drop-in replacements for telnet, ftp, and the BSD r-commands. Like SSL, SSH operates at the application layer, but can nonetheless be used to build true network-to-network VPNs.

Chapter 8 concludes Part 2 with a discussion of several lightweight VPNsVTun, CIPE, tinc, and Open VPNand examines their strengths and weaknesses. In all but one case, these VPNs are implemented in user space, and so make use of the gtunnel-like capabilities that are examined in Chapter 4.

This chapter is particularly revealing because it exposes many of the security problems that a VPN designer must consider. The four VPNs vary greatly in their security and robustness, and these differences highlight common mistakes in implementing secure software.

IPsec

Part 3 is a detailed examination of IPsec, the IETF standard VPN technology. IPsec operates at the network layer and is thus largely indifferent to the type of traffic it is carrying. IPsec is transparent to applications; they are not aware of its existence.

Chapter 9 provides a brief introduction and road map. Chapter 10 discusses the IPsec architecture: the protocols, modes, and databases that make up the IPsec suite. Each of the following three chapters discusses one of the three protocols that make up IPsec.

Chapter 11 discusses the Authentication Header (AH) protocol and how it provides data origin authentication, message integrity, and protection from replay attacks. The algorithms used to provide replay protection receive detailed attention, as do the two modes of AH encapsulation. Chapter 12 examines the Encapsulating Security Payload (ESP) protocol, which can provide the essentially identical services that AH does, as well as privacy through encryption. Thus although third parties can read but not tamper with messages protected by AH, they can neither read nor tamper with messages protected by ESP. As with AH, the two encapsulation modes receive careful examination.

The Internet Key Exchange (IKE) protocol is the third IPsec protocol. This key-management protocol is examined in Chapter 13. By far the most complicated of the three protocols, IKE is largely responsible for IPsec's reputation as a complicated and difficult protocol. The chapter examines how IKE negotiates security associations between peers, and how it derives the keys used by AH, ESP, and IKE to secure their communications.

Part 3 ends with Chapter 14, which discusses the near-term future of IPsec. First, the chapter examines the new versions of AH, ESP, and IKE that are currently under IETF development. Then it discusses the recently standardized NAT traversal mechanisms that provide IPsec and NAT with some degree of interoperability.


Section 1.7. Summary

1.7. Summary

This introduction laid out the purpose and prerequisites of the text. The chapter discussed typographical conventions, source code, and third-party software that the book will use. Finally, it provided a detailed road map for the rest of the book.


Chapter 2. TCP/IP Overview

    Section 2.1. Introduction

    Section 2.2. Layering

    Section 2.3. Encapsulation

    Section 2.4. Addressing

    Section 2.5. IP

    Section 2.6. UDP

    Section 2.7. TCP

    Section 2.8. ICMP

    Section 2.9. NAT and Private IP Addresses

    Section 2.10. PPP

    Section 2.11. IPv6

    Section 2.12. Routing

    Section 2.13. Summary

    Exercises


Section 2.1. Introduction

2.1. Introduction

The flow and routing of data on the Internet is controlled by a set of protocols called the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. These protocols provide many sorts of services. Some protocols provide a connectionless, best-effort, datagram delivery service. Others provide a connection-based reliable data delivery service. Still others provide routing, name resolution, and network control messaging. Together, the TCP/IP protocols form an infrastructure that applications can use to communicate with peer applications on machines across the room or across the world.

Before beginning our examination of the role of tunnels and VPNs in networking, let's review some of the basic facts about TCP/IP and its use in the Internet. This chapter looks at the major protocols that we will build on later in the text. We will recall their normal operating modes, their data formats, and their operation on the wire. The subject is a large one, of course, so our coverage will be a précis rather than an exhaustive account. A detailed treatment of TCP/IP along the lines of our review is given in [Stevens 1994]. Another excellent account of TCP/IP [Comer 2000], takes a slightly different view.


Section 2.2. Layering

2.2. Layering

Layering is an important conceptual tool that helps us to organize, understand, and deal with the complexity of network architecture. The idea is to divide the network's functions into layers. Each layer makes use of the services of the layer below it to provide a set of specific services for the layer above it. Adjacent layers communicate with each other through a well-defined interface, so that in principle, we could change one layer or even completely rewrite it without affecting the others.

Together, the layers are said to constitute a stack. The TCP/IP stack comprises four layers, as shown in Figure 2.1.

Figure 2.1. The TCP/IP Stack

Listed to the right of the stack are some of the protocols that operate in each layer.

The four layers and their functions are:

  1. The interface layer comprises the operating system device driver and associated network interface hardware. This layer handles the details of getting the bits from the network layer's datagrams onto the wire. Typical examples of protocols at this layer are Ethernet, Token Ring, Fiber Distributed Data Interface (FDDI), and the Point-to-Point Protocol (PPP). The interface layer is sometimes called the link or datalink layer.

  2. The network layer is primarily concerned with routing IP datagrams through the Internet. It also carries Internet Control Message Protocol (ICMP) messages, which contain error and control information about the network, and Internet Group Management Protocol (IGMP) messages, which help with the management of multicast messaging. Because the network layer's most important task is to handle IP datagrams, it is sometimes called the Internet layer.

  3. The transport layer is concerned with end-to-end communications. Whereas the network layer is concerned with moving an IP datagram from one host or router to the next, the transport layer is concerned with communication between the two ultimate destinations, as illustrated in Figure 2.2. As shown in that figure, the transport layer views itself as logically directly connected to its peer transport layer on the destination host. The two most important transport-layer protocols are TCP and the User Datagram Protocol (UDP).

    Figure 2.2. Communication Between Corresponding Layers

    [View full size image]

  4. The application layer is where the applications reside. Typical examples are such standard TCP/IP applications as ftp, ssh, and email, as well as user-written applications. As with the transport layer, the application layer is logically directly connected to its peer layer on the destination host.

It is common to find references to the seven-layer Open Systems Interconnection (OSI) reference model [International Standards Organization 1984] in networking literature. In that model, the network, transport, and application layers are numbered 3, 4, and 7, respectively. To avoid confusion between the two models, we will always refer to layers by their names rather than their numbers. When numbers are used in networking literature, they almost always refer to the OSI model. Thus, for example, layer 4 refers to the transport layer. See Tip 14 in ETCP for more on the OSI model and how it relates to the TCP/IP stack.

Beginners are often confused about the difference between the network and transport layers. Figure 2.2 makes the distinction clear. The network layer carries on a conversation with its peer network layer on the next hop, whereas the transport layer carries on a conversation with its peer layer on the final destination. To put it another way, the transport layer behaves as if it were directly connected to its peer layer and is unaware of the actual path that its data takes through the network. The network layer, on the other hand, is concerned with choosing the path that the data takes and, as such, is involved with processing at each hop. Note from the figure that routers do not necessarily even have transport layers.


Section 2.3. Encapsulation

2.3. Encapsulation

As we shall see later in the text, the notion of encapsulation is fundamental to tunneling and VPNs. We needn't wait until we discuss tunnels to see encapsulation in action, however. As data travels down the stack on its way to the network cable or other media, each layer adds a header and, possibly, a trailer to the data. We say that each layer encapsulates the data from the previous layer.

This notion is illustrated in Figure 2.3, which shows data for a TCP session moving through the stack. The data that, say, the user types in at the console is encapsulated by the application layer, which adds an application header. When the encapsulated application data enters the transport layer, it is encapsulated into a TCP segment by the addition of a TCP header. Similarly, when the TCP segment arrives at the network layer, IP adds its own header, encapsulating the TCP segment into an IP datagram. Finally, when the IP datagram gets to the interface layer, the Ethernet driver encapsulates it in an Ethernet frame by adding a header and trailer.

Figure 2.3. Data Encapsulation in the TCP/IP Stack

[View full size image]

As it moves up the stack at the destination, data is decapsulated at each layer so that that layer sees exactly the same data as its peer. For example, when a TCP segment arrives at the destination host and moves up the stack to the transport layer, TCP will see exactly the same data as that sent by TCP on the source host. Similarly, the application layer will see the same data that the application on the source host sent. It is in this sense that the peer transport and application layers are logically directly connected. Whatever the lower layers on the source host do to the data, the lower layers on the destination host undo.

It is important to be aware that, at the network and interface layers, the peer is the next hop, not the ultimate destination, as shown in Figure 2.2. The network layer at the source host is carrying on a conversation with the router at the next hop, not the destination host. As the IP datagrams move through each router, the router changes some of the fields in the IP header, so that the IP layer at the destination host will not, in general, see the same data that the source host sent. Each hop's network layer will see the exact data that the previous hop sent.

Figure 2.4 shows a tcpdump of data, such as that depicted in Figure 2.3, as it enters the interface layer. That is, the dump of the data is just before the Ethernet framing is added.

Figure 2.4. Encapsulated Data

[View full width]
1   05:58:10.846770 172.30.0.12.1027 > 172.30.0.1
  .5000: P
    1146985371:1146985392(21) ack 1409259751 win 57920
    <nop,nop,timestamp 51296 889418481> (DF)
1.1     4500 0049 007c 4000 4006 e1e9 ac1e 000c  E
  ..I.|@.@.......
1.2     ac1e 0001 0403 1388 445d 9b9b 53ff 98e7  .
  .......D]..S...
1.3     8018 e240 7b3a 0000 0101 080a 0000 c860  .
  ..@{:.........'
1.4     3503 72f1 0000 0011 4441 5441 4441 5441  5
  .r.....DATADATA
1.5     4441 5441 4441 5441 0a
   DATADATA.

We'll look at each stage of the encapsulation as we cover the relevant protocols. For now, note the data in boldface on lines 1.4 and 1.5. This is the encapsulated application data. As shown in Figure 2.5, the first 4 bytes are the length of the user data (0x11 = 17), followed by 17 bytes of user data.

Figure 2.5. Encapsulated Application Data

[View full size image]

Not every application encapsulates its data in this way, of course. As we shall see, some add larger headers and trailers, and some add no headers at all.


Section 2.4. Addressing

2.4. Addressing

In this section we discuss IP addresses, but before we begin, we should be clear on what that means. IP uses IP addresses to route packets from one host to another. These hosts may or may not be on the same physical networkon the same Ethernet cable, sayso an IP address is not the same thing as a physical address, such as an Ethernet address. In terms of Figure 2.3, IP addresses are used by the network layer, whereas physical addresses are used by the interface layer.

A version 4 IP address is a 32-bit integer. IP addresses are usually written as four decimal numbers connected by dots; we call this dotted decimal notation. Each decimal number is the value of 1 byte of the 32-bit address. Thus, we would write 1.2.3.4 rather than 0x01020304 or, worse yet, 16,909,060. Traditionally, IP addresses were divided into five classes, as shown in Figure 2.6. The division of the address space into classes was intended to make address allocation more flexible. Class D addresses are used in multicastingsending an IP datagram to a group of hosts rather than to a specific host on the network. Class E addresses are used for experimental purposes, and we won't consider them further.

Figure 2.6. IP Classful Addressing

Each interface on a host has at least one Class A, B, or C address assigned to it. These are the addresses that are used to send IP traffic to a specific machine.

More precisely, they are the addresses used to send IP traffic to a specific interface on a specific machine.

Although part of the address, we can think of the first few bits of an IP address as identifying the network class, as shown in Figure 2.6. The network ID field identifies the network that this address belongs to. Routers use this field to route IP datagrams through the Internet or other wide area network (WAN). The size of the network ID field depends on the address class, which is determined by the leading bits.

The host ID field identifies a particular host on the network specified in the network ID field. The host ID is arbitrary; the system administrator in charge of the network assigns it in any way that is convenient. This field is not used in routing datagrams outside its home network.

Figure 2.7 shows the number of networks and hosts and the ranges for Class A, B, and C addresses.

Figure 2.7. Networks, Hosts, and Ranges for Class A, B, and C Addresses

Class

Networks

Hosts

Address Range

A

128

16,777,214

0.0.0.1 to 127.255.255.255

B

16,384

65,534

128.0.0.0 to 191.255.255.255

C

2,097,152

254

192.0.0.0 to 223.255.255.255

The figure clarifies the distinction between Class A, B, and C addresses: Class A addresses are for the few networks with a huge number of hosts. Class C addresses are for the many networks with just a few hosts. Class B addresses are for networks with a moderate number of hosts.

The host IDs consisting of all 1-bits or all 0-bits are reserved. That's why, for instance, Class C networks have only 254 hostshost 0 and host 255 are reserved. Network 127 is also reserved; it is used for the internal loopback address. Datagrams addressed to this network are looped back up the stack and never leave the machine.

Although classful addressing is still prescribed in the standards, it is too inflexible to meet the needs of modern networks. There are several problems with classful addressing, so let's consider it first from the point of view of the holder of a Class A or B address block. Conceptually, each network corresponds to a group of machines that are connected by some networking medium, such as an Ethernet cable. But no one puts 65 thousand, let alone 16 million, hosts on a single cable. Instead, the network is organized into several smaller segments, each with its own physical network medium, and these segments are connected with routers. Figure 2.8 shows an example of this with just two segments.

Figure 2.8. Two Segments Connected by a Router

If host 1 wants to send an IP datagram to host 2, it need merely map host 2's IP address to its physical address and put the datagram on the wire. Now consider what happens if host 1 wants to send a datagram to host 4: Even if it knows or is able to determine host 4's physical address, host 1 can't send the datagram directly to host 4, because it's on a different physical network. Thus, host 1 must send the datagram to host 4 indirectly through router 2.

This raises the question of how host 1 knows that it must send the datagram to router 2. One possibility is for router 2 to masquerade as the hosts on segment 2 for any host on segment 1, and as the hosts on segment 1 for any host on segment 2. For Ethernet segments, this is called proxy ARP.

ARP (Address Resolution Protocol) is used to find a host's Ethernet media access control (MAC) address from its IP address by broadcasting a message to all hosts on the Ethernet segment, asking the host with the target IP address to send the requesting host its MAC address. ARP is defined in [Plummer 1982].

When host 1 tries to map the IP address of host 4 to a physical address, router 2 replies with its physical address, and then forwards the datagram onto host 4 when it arrives. The problem with this solution is that it does not work with every type of physical network, and that even when it does, it doesn't scale well to complicated network topologies.

Another possible solution is to add entries to host 1's routing table for each host on segment 2 listing router 2 as the next hop. This solution will work for any type of physical network but clearly doesn't scale to more than a few hosts. For a large network, the routing tables would be unworkably large and their administration daunting.

The problem is that both segments have the same network ID. If we imagine for a moment that they had different network ID's, the difficulty largely disappears. Suppose that all the hosts on segment 1 have Class C addresses of the form 192. 168. 1. n and that all the hosts on segment 2 have addresses of the form 192. 168. 2. n. In this case, segment 1 hosts have a network ID of 192.168.1, and segment 2 hosts have a network ID of 192.168.2. We now need add only a single entry to the routing table of each host on segment 1 specifying router 2 as the next hop for network 192.168.2. We add a similar entry to the routing table of each host on segment 2. We can easily see that this method would scale well to large networks.

This solution brings its own problems, however. When both segments had the same network ID, hosts outside the network needed only a single routing table entry to route to any host in the network. If each segment has its own network ID, outside hosts will need a routing table entry for each segment. That doesn't matter much for a single organization with two segments, of course, but imagine thousands of organizations with hundreds of segments, and the problem becomes clear. Routers, especially the high-speed routers in the Internet's core, often put their routing tables in special highspeed memory on the link interface cards, and because the amount of this memory is limited, the large routing tables envisioned by our solution wouldn't work.

This problem is not merely theoretical. [Huitema 2000] recounts some real-world examples of router failure caused by the growth of routing tables.

What we need is a solution that lets hosts inside an organization see each segment as a separate network but that lets hosts outside the organization see a single network. A simple solution of this sort, called subnetting, does exist. The basic idea is that part of the host ID is used to specify the segment, or subnetwork, and the internal routers know about this. External routers don't concern themselves with the host ID portion of the address, so they need only a single routing table entry for the entire organization's network. The complete details are given in RFC 950 [Mogul and Postel 1985].

CIDR

Subnetting is subsumed in a more general solution, so rather than discuss it in detail, let's consider the problems of classful addressing from the point of view of an organization that needs several hundred or thousand IP addresses. Ideally, such an organization would like a Class B address block. A single Class C block doesn't have enough addresses, and using several Class C blocks reintroduces the problem of routing table growth.

As we see from Figure 2.7, only 16 thousand Class B address blocks are available, and most of those have already been assigned. That leaves multiple Class C address blocks as the only solution. To avoid the problem of routing table growth, we use a scheme called classless interdomain routing (CIDR).

An example will make clear how CIDR works. Suppose that an organization needs 1,000 IP addresses. Under CIDR, we would allocate the organization four Class C blocks that share the same most significant bits200.10.4.0 through 200.10.7.0, say. Note that the upper 22 bits of each address in these blocks are the same. We use these 22 bits as the network ID for the organization, and we write the network ID as 200.10.4.0/22. The "22" is called the prefix, or network mask.

The prefix specifies how many of the most significant bits of the IP address make up the network ID. The prefix is really just a compact way of specifying the network mask, which is a 32-bit integer with the prefix most significant bits set to 1. Thus, a prefix of 22 corresponds to a network mask of 0xfffffc00. In practice, the two terms are used interchangeably.

Notice that 200.10.4.0/22 and 200.10.4.0/24 are not the same: The first has a network ID of 0x320281, whereas the second has a network ID of 0xc80a04.

Obviously, routers must know the subnet mask so that they can extract the network ID to route the datagram. Thus, under CIDR, the network mask becomes part of the routing table entry for all routers. Recall that with classful addressing, external routers didn't need this information, because they used the first few bits of the IP address to determine the portion of the address making up the network ID.

CIDR solves the opposite problem too. Suppose that instead of an organization needing 1,000 addresses, we have a home network that needs only 5. In that case, we can allocate part of a Class C block200.10.4.0, sayby using a 29-bit prefix. Note that we can suballocate the block into 32 such smaller networks.

The classless part of CIDR comes from the fact that we completely ignore the original division into Class A, B, and C addresses, and use the network mask to determine the network ID instead. Thus, even though we often hear people say that 200.10.4.0/22 combines four Class C blocks or that 200.10.4.0/29 is part of a Class C block, in reality, Class C blocks no longer exist. CIDR generalizes the Class A, B, C division by allowing us to fix the network/host ID boundary at any bit.

Now let's review how CIDR solves the problems with classful addressing. We've just seen how it remedies the problem of Class B address block depletion by combining Class C blocks, and how it helps with IP address depletion in general by allowing networks with fewer than 254 hosts.

Our organization with the 200.10.4.0/22 network will probably partition its network into several segments as we discussed above. This reintroduces the internal routing problem that using more than one segment entails. However, because the network mask is part of the routing table entry, the internal routers can use a different prefix. For example, suppose that the organization divided the 200.10.4.0/22 network into four segments. The segments would have the network IDs 200.10.4.0/24, 200.10.5.0/24, 200.10.6.0/24, and 200.10.7.0/24. The internal routers would have a routing table entry for each of these segments with a prefix of 24 and a next hop of the appropriate router.

Although we divided the 200.10.4.0/22 network back into its constituent Class C blocks, that isn't necessary. We could just as well suballocate it into two subnetworks with a 23-bit prefix and 510 hosts or eight subnetworks with a 25-bit prefix and 126 hosts, and so forth.

To help make these ideas clear, let's assume that our example organization with the 200.10.4.0/22 network decides to split the network into two segments, as in Figure 2.8. The system administrator might decide to assign the hosts on segment 1 to the 200.10.4.0/23 network and the hosts on segment 2 to the 200.10.6.0/23 network. Figure 2.9 shows the two segments of Figure 2.8 redrawn and labeled with their network addresses. Each router interface has been labeled with the network address that it reaches, and each host has been labeled with the last 2 bytes of its IP address.

Figure 2.9. Two Segments with Suballocated Network Addresses

[View full size image]

What would the routing table for host 1 look like? Because it is directly connected to the 200.10.4.0/23 network, it can send datagrams to hosts on that network directly and doesn't need a next hop. We'll indicate that by specifying the next hop as "local." The only way to reach the 200.10.6.0/23 network is through router 2, so we will need an entry for that. All other datagrams will have destinations outside the 200.10.4.0/22 network, so we will need a default route listing router 1 as the next hop. Thus, our routing table would look like Figure 2.10.

Figure 2.10. The Routing Table for Host 1

Route

Prefix

Next Hop

200.10.4.0

23

local

200.10.6.0

23

router 2

default

router 1

Suppose again that host 1 wants to send a datagram to host 4. As shown in Figure 2.9, host 4 has the IP address 200.10.6.1. Host 1 will consult each entry in its routing table and will AND the network mask of the entry with 200.10.6.1. If the result matches the route, then this is a candidate entry to use for routing. If more than one entry matches, the one with the longest match is used. In this case, the 200.10.6.0/23 entry is the best (and only) match, so host 1 will send the datagram to router 2.

CIDR is discussed in detail in RFCs 1517, 1518, and 1519 [Hinden 1993, Rekhter and Li 1993, Fuller, Li, Yu, and Varadhan 1993]. Tip 2 of ETCP discusses subnetting and CIDR in a little more detail.

Broadcast Addresses

Before leaving the subject of IP addressing, let's take a quick look at broadcast addresses, which are used to send a datagram to all hosts on a segment or a network. With CIDR, there are two types of broadcast address:

  1. Limited broadcast

  2. Network-directed broadcast

A datagram cannot be broadcast outside the network of the host sending it. If we think about the mischief that a malefactor could cause by being able to broadcast a datagram to every host on the Internet, we see that this restriction makes sense. For example, a broadcast with a forged source address would cause every receiving host to reply, resulting in a very efficient denial-of-service attack.

The limited broadcast address is 255.255.255.255. It is called limited because routers will never forward datagrams with that destination address. This means that datagrams with the limited broadcast address are confined to the particular network segment on which they originate. A typical use for the limited broadcast address is for a host to map an IP address to a physical address. With Ethernet, for example, a host wishing to determine the physical address of some other host from its IP address broadcasts a request asking the holder of that IP address to send the original host a message with its physical address. All hosts on the segment will receive the request, but only the holder of the target IP address will respond. Other uses are with the Dynamic Host Configuration Protocol (DHCP), used by hosts to obtain an IP address when they boot, and the BOOTP protocol, used by diskless workstations to get their boot images.

The network-directed broadcast address has the normal network ID of the specified network, and the host ID set to all ones. Thus, if host 1 of Figure 2.9 wanted to send a broadcast message to every host on the 200.10.4.0/22 network, it would address the datagram to 200.10.7.255. Because of security problems with this type of address, routers are often configured to not forward them.

Smurf attacks are an example of how network-directed broadcasts can be misused. The Smurf attack is another denial-of-service attack; a datagram with a forged source address is sent to a network-directed broadcast address, causing each host on the network to reply to the forged address.


Section 2.5. IP

2.5. IP

IP provides a connectionless, unreliable datagram delivery service. Connectionless means that the transmission of each datagram is a distinct event, and no state is maintained by the host about previously sent datagrams. Unreliable means that IP makes no guarantees about whether the datagram will be delivered and, if it is, whether it will be delivered in order with respect to other datagrams.

The standard analogy is that IP is like sending a letter or postcard. We separately address each letter that we send, even if it is going to the same correspondent as our last letter. The post office handles our letters without regard to any other letters we may have sent to the same correspondent; that is, it does not maintain state between letters. Nor does the post office guarantee that our letters will not be lost, delayed, or delivered out of order.

Note that we are talking about IP here. It may be that the application or transport layer is maintaining state and providing reliability. The point is that IP isn't doing so.

Given that IP provides such a bare-bones service, we might ask why we bother with it at all. Why not merely define a reliable service in the first place? The answer is that IP provides a simple building block upon which other, more robust, protocols can be built.

When viewed from abovefrom the upper layers in the stackIP provides a simple packet-transport vehicle that makes no assumptions about the packets it will be carrying. The upper layers simply load the data and tell IP where to deliver it. IP does not care about or look at the data it is carrying. This means that IP is capable of serving as a delivery mechanism for a wide variety of upper-level protocols.

The view from belowfrom the physical medium on which IP runsis of a very undemanding protocol. Because it assumes nothing about the underlying medium except that it is capable of routing packets, IP can run on any type of physical network that can carry packets. Thus, IP can, and does, run on a wide variety of physical networks. A few of the (widely different) physical networks that IP runs on are serial lines, Ethernet, Token Ring, asynchronous transfer mode (ATM) WANs, X.25, FDDI, cellular digital packet data (CDPD), and 802.11 WiFi. There are many others. The fact that IP runs on all these physical networks means that the upper-layer protocols, such as UDP and TCP, do too. We see, therefore, that the simplicity of IP is its chief strength. The IP specification is given in RFC 791 [Postel 1981a].

The IP Header

Figure 2.11 shows the format of the IP header. This is the header for version 4 of IP. See Figure 2.37 for the version 6 header format. The length of the header in 32-bit words is given in the hdr. len. field. For the normal case, in which the IP header contains no options, this will be a 5.

Figure 2.11. The IPv4 Header

[View full size image]

The type of service field contains either a precedence value and bit field specifying how routers should handle the datagram, or it contains explicit congestion notification (ECN) information.

The total length field is the length in bytes of the complete datagram, including the headers. This field is 16 bits, so the maximum sized IP datagram is 65,535 bytes.

Even though an IP datagram can be up to 65,535 bytes, most physical networks can't handle packets that large. Ethernet, for example, has a maximum payload, called the maximum transmission unit (MTU), of 1,500 bytes. If an application tries to send a datagram larger than the MTU of the interface, IP breaks the datagram into smaller fragments. Even if the datagram is smaller than the MTU of the sending host's interface, it may encounter a smaller MTU at one of the intermediate hops, causing the router to fragment the datagram.

If a datagram is fragmented, the total length field will contain the size of the fragment, and the fragment offset field will contain the offset of the fragment in the original datagram. Every fragment except the last will have the more fragments (MF) bit set. The fragments of an IP datagram are tied together with the identification field. Every IP datagram that a host sends will have a unique (modulo 216) identification number, so even if the datagram is fragmented by an intermediate router, the destination host will have the required information to reassemble the datagram. Hosts can signal routers not to fragment a datagram by setting the don't fragment (DF) bit. This bit is useful for discovering the minimum MTU on the path from source to destination in a process called path MTU (PMTU) discovery. The PMTU discovery process is described in RFC 1191 [Mogul and Deering 1990].

To prevent IP datagrams from circulating in the Internet indefinitelybecause of a router loop, sayeach datagram carries a time to live (TTL) value. The sending host initializes the TTL to some value (typically 32 or 64), and the router at every hop decrements it by 1. If the TTL reaches 0 before it arrives at its destination, the datagram is dropped, and an error message is sent back to the source host, using ICMP.

IP datagrams are used to carry upper-layer protocols and, sometimes, network-layer protocols, such as ICMP. The type of protocol that the datagram is carrying is in the protocol field. Some important protocols and their values are shown in Figure 2.12.

Figure 2.12. Internet Protocols

Protocol

Value

Description

ICMP

1

Internet Control Message Protocol

IGMP

2

Internet Group Management Protocol

IP/IP

4

IP-in-IP

TCP

6

Transmission Control Protocol

UDP

17

User Datagram Protocol

IPv6

41

IP version 6

GRE

47

Generic Routing Encapsulation

ESP

50

Encapsulating Security Payload

AH

51

Authentication Header

OSPF

89

Open Shortest Path First Routing Protocol

L2TP

115

Layer Two Tunneling Protocol

The fields in the IP header are protected by the standard Internet checksumsee RFC 1071 [Braden, Borman, and Partridge 1988]. After the header is completely filled in, IP calculates the checksum and places it in the IP header checksum field. Note that the IP header checksum covers only the header itself, not the data that the datagram carries. This means that the upper-layer protocols must provide their own checksums if they require one.

The source address and destination address fields hold the 32-bit source and destination IP addresses. We discussed IP addresses in Section 2.4.

Looking at lines 1.1 and 1.2 from Figure 2.4, we see the IP header encapsulating the upper-layer protocols:

1.1       4500 0049 007c 4000 4006 e1e9 ac1e 000c   E..I.|@.@.......
1.2       ac1e 0001 0403 1388 445d 9b9b 53ff 98e7   ........D]..S...

The 45 in the first byte tells us that this is an IPv4 datagram (first 4 bits) with a header size of 20 bytes (second 4 bits). The third and fourth bytes tell us that the entire datagram is 73 (0x49) bytes. We see from the ninth byte that the operating system (FreeBSD, in this case) has set the initial TTL to 64 (0x40). The next byte tells us that the datagram is encapsulating protocol 6. From Figure 2.12, we see that this is TCP. Finally, we see that the sending host's IP address is 172.30.0.12 (0xac1e000c), and that it is sending the datagram to 172.30.0.1 (0xac1e0001).


Section 2.6. UDP

2.6. UDP

The User Datagram Protocol (UDP) enables user applications to send and receive connectionless, unreliable datagrams. As a transport-layer protocol, UDP is carried in IP datagrams, as shown in Figure 2.13.

Figure 2.13. UDP Datagram Encapsulation

[View full size image]

UDP adds very little to the basic IP service on which it depends. First, UDP provides the ability to associate a UDP datagram with the sending and receiving processes through the source and destination port numbers. Recalling our earlier analogy of IP being like sending a letter, we could say that the IP address corresponds to the street address of an apartment building, whereas the port number corresponds to individual apartments. In any event, the receiving UDP uses the destination port number to demultiplex the UDP datagram to the proper application. If the application sends a reply, it will address the reply to the host given in the source address field of the IP header and the application given by the source port number.

The other addition that UDP brings to the basic IP service is an optional checksum. We call the checksum optional because a host can disable its validation by setting it to 0. When present, the checksum covers the entire UDP datagramheader and data.

Actually, the checksum includes a little more. Before calculating the checksum, a pseudoheader that includes the source and destination addresses, the protocol, and the length of the IP payload is prepended to the UDP header. This header is not transmitted; it is merely used for calculating the checksum:

Notice that the length of the UDP datagram is checksummed twice. Although this appears redundant for UDP, it makes more sense for TCP, which also uses the pseudoheader for calculating the checksum, because TCP doesn't have an explicit length field.

The UDP header is shown in Figure 2.14. The source port and destination port hold the port numbers. The checksum field is either the UDP checksum or 0.

Figure 2.14. The UDP Header

[View full size image]

The length field holds the total length of the datagram, including the header. Note that this field isn't really necessary, because the UDP datagram's length can be inferred from the length field of the encapsulating IP datagram. We shall see, in fact, that TCP does not have an explicit length field. UDP is specified in RFC 768 [Postel 1980].


Section 2.7. TCP

2.7. TCP

The Transmission Control Protocol (TCP) provides a reliable, connection-based byte stream delivery service. The last sentence is ripe with meaning, so let's spend a little time exploring what it means.

We have seen that IP and UDP are best-effort protocols. They make no guarantees that they will deliver a datagram or if they do, that they will deliver it in order. Because IP does not checksum its payload, and because the UDP checksum is optional, these protocols don't even guarantee that any data they do deliver will arrive uncorrupted.

TCP, on the other hand, is prepared to make some guarantees. It guarantees that any data that arrives at the destination will be in order and uncorrupted.

We should be more precise here. When we say that TCP guarantees that the data will be uncorrupted, we mean that it guarantees it to the extent that the 16-bit Internet checksum is able to detect corruption.

Reliability also means that TCP agrees to try really hard to deliver all the data that the sender commits to it for transmission to the destination. It does this by demanding acknowledgments from its peer TCP that data has arrived and by retransmitting the data after a suitable time if it does not receive an acknowledgment. Reliability most emphatically does not mean that TCP unconditionally promises to deliver any data that the sender writes. Even a moment's thought will convince us that TCP couldn't possibly keep that promise under all circumstances. For more on what reliability means and doesn't mean, see Tip 9 of ETCP.

In order to implement its retransmission strategy, TCP must maintain state between the blocks of data, called segments, that it sends to its peer. It does this by establishing a logical connection with its peer. The usual analogy is that TCP is like a phone call: A connection is established, words are delivered in the order that they are spoken, and it is not necessary to address each sentence or word by, say, continually redialing the peer's number. When the parties finish their conversation, they say goodbye and hang up, and the connection is torn down. As we shall see, TCP goes through similar stages: A connection is established, the peers exchange data without needing to specify their peers' addresses with each write, and when they are finished, the connection is torn down.

The telephone analogy is a useful one for understanding the difference between connectionless and connection-based protocols, but it can be misleading. With a phone call, a physical connection is established, but the TCP connection is entirely notional, consisting only of shared state maintained by the two peers. The data itself, as shown in Figure 2.15, is carried in an IP datagram, just as it is for IP, ICMP, and UDP.

Figure 2.15. TCP Encapsulation

[View full size image]

One of the most common misunderstandings about TCP involves its data delivery model. TCP delivers a byte stream to the receiving application. This means that TCP has no notion of records or packets that are visible at the user level. Suppose that an application writes a series of 500-byte messages. On any given read, the receiver may read part of one of those messages, all of one of the messages, or more than one of the messages. As Varghese [Varghese 2005] puts it, TCP simulates a shared data queue into which the sender puts bytes and the receiver removes bytes. There is no way for the receiving TCP to tell whether or not 2 bytes were put into the queue at the same time.

This is not to say that the application cannot impose its own record structure on the byte stream, only that TCP doesn't do so. Figure 2.5, for example, shows one way for an application to do this. Explicit record markers, such as newlines in textual data, are another. Later in the text, we will see several examples of applications or other protocols running over TCP imposing their own record structure on the byte stream.

From the preceding discussion, the meaning of our description of TCP as a reliable, connection-based, byte stream delivery service should now be clear. Notice how this service is the antithesis of UDP, which is an unreliable, connectionless, datagram delivery service. The TCP specification is given in RFC 793 [Postel 1981b].

The TCP Header

As we mentioned above, TCP sends its data in blocks called segments. The format of these segments is shown in Figure 2.16. The source port and destination port serve to identify the sending and receiving applications, just as they do in UDP datagrams.

Figure 2.16. The TCP Header

[View full size image]

In TCP, every byte has a sequence number. We do not, of course, attach a sequence number to every byte. Instead, the sequence number of the first byte in a segment is placed in the sequence number field. The sequence numbers of the remaining bytes in the segment are then known by implication.

As we shall see when we discuss the TCP flag bits, the SYN and FIN bits also take up a sequence number.

When TCP receives a segment from its peer, it returns the sequence number of the next byte it is expectingthat is, the sequence number after that of the largest-numbered byte it has receivedin the acknowledgment number field. This serves as an acknowledgment to its peer that TCP has received all bytes up to but not including the byte numbered in the acknowledgment number field. If the receiving peer has data of its own to send, it piggybacks the acknowledgment number in the data segment. Otherwise it sends the acknowledgment in a segment without any data. Every segment after the first (SYN) segment must specify the next byte it is expecting from its peer in the acknowledgment field.

TCP uses sequence numbers to ensure that applications receive the data in order. Most TCPs will queue any out-of-order data they receive until the missing bytes arrive. It is legal, however, for TCP to merely drop the data and send an acknowledgment indicating the data it is expecting.

The TCP header is nominally 20 bytes but commonly contains optional data, such as timestamps or announcements concerning the maximum segment size the peer is willing to accept. TCP puts the size of the header, including options, in 32-bit words in the data offset field.

There are six flags that TCP can set in the header:

SYN | This flag is set in the initial segment when a new connection is being set up. When the SYN flag is set, it has the sequence number given in the sequence number field, and the first byte of data has the next sequence number.
FIN | This flag serves as an EOF indicating that the TCP that set it is through sending data, although it may be willing to accept more data. When this flag is set, it has the sequence number after that of the last byte of data in the segment.
ACK | This flag is set when the value in the acknowledgment number field is valid. The ACK flag must be set in every segment except possibly the first when the SYN segment is set.
RST | This flag is used to reset the connection. Its most common use is during connection setup to indicate that no application is listening for a connection on the destination port. The flag is also used to immediately abort a connection under certain error conditions.
PSH | This flag is intended to indicate that the receiver should deliver any data in its receive buffer to the application but is virtually always ignored by the receiver. Senders often set it when the current segment empties the send buffer.
URG | This flag indicates that urgent data is available in the byte stream at the offsetfrom this segmentshown in the urgent pointer field. The meaning and use of this field are widely misunderstood. See [Stevens 1998] for some guidance on its use.

TCP provides flow control by telling its peer how much data it is currently willing to accept. It does this by advertising a receive window in the window size field. The receive window is the number of bytes, starting with the one numbered in the acknowledgment field, that TCP has space to buffer. When TCP has exhausted the buffer space for a connection, it will advertise a zero-sized window, and its peer will not send it any more data until it advertises a positive window size again.

TCP has a mandatory checksum, which is placed in the checksum field. As with IP and UDP, the checksum is the standard Internet checksum. Also as with UDP, the checksum is calculated over the pseudoheader, the TCP header and options, and the TCP data.

Looking at lines 1.21.4 from Figure 2.4, we see the TCP header of the segment encapsulated in the IP datagram:

1.2   ac1e 0001 0403 1388 445d 9b9b 53ff 98e7   ........D]..S...
1.3   8018 e240 7b3a 0000 0101 080a 0000 c860   ...@{:.........'
1.4   3503 72f1 0000 0011 4441 5441 4441 5441   5.r.....DATADATA

The first 12 bytes are the source and destination ports, the sequence number of the first byte of data, and the acknowledgment number. The destination port number, for example, is 5000 (0x1388).

The first 2 bytes in line 1.3 tell us that the TCP header is 32 bytes (8 words) long and that the PSH and ACK flags (0x18) are set. A good exercise is to verify the rest of the fields with line 1 of Figure 2.4. We had tcpdump print that line in a way that makes it easy to see the exact values.

Normally, tcpdump prints sequence and acknowledgment numbers relative to the sequence number of the SYN bytes. This makes the numbers smaller and easier to follow. For Figure 2.4, we inhibited that behavior. We also asked tcpdump to print numeric rather than symbolic addresses.

Connection Setup: The Three-Way Handshake

The normal connection sequence is shown in Figure 2.17.

Figure 2.17. TCP Three-Way Handshake

One of the peers, usually called the client, initiates the connection by sending its peer, usually called the server, a SYN segment that has an initial sequence number and perhaps some other connection parameters. The server responds by acknowledging the client's SYNwe say that the server ACKs the SYNand sending its own SYN segment with an initial sequence number and optional connection parameters. The client ACKs the server's SYN, and the connection is established.

Sometimes, we say that the connection is synchronized, meaning that the two peers have synchronized their connection state. The term SYN is often used as shorthand for synchronization segmenta segment with the SYN flag set.

We can see the handshake in action by using tcpdump to capture a TCP session. On laptop, we use netcat (nc) to connect to the echo server on solaris:

laptop:~
$ nc solaris echo
hello
hello
^C punt!

We run tcpdump on laptop to capture the connection setup. In this case, we didn't ask tcpdump to print a hex dump of the datagrams:

1   05:57:05.603882 laptop.1033 > solaris.echo:
    S 544197796:544197796(0) win 57344
    <mss 1460,nop,wscale 0,nop,nop,timestamp 75371 0> (DF)
2   05:57:05.631720 solaris.echo > laptop.1033:
    S 3156319241:3156319241(0) ack 544197797 win 24616
    <nop,nop,timestamp 1559953062 75371,nop,
    wscale 0,mss 1460> (DF)
3   05:57:05.631927 laptop.1033 > solaris.echo: . ack 1 win 57920
    <nop,nop,timestamp 75374 1559953062> (DF)

In line 1, laptop sends a SYN segment to solaris asking to establish a connection with the application listening on port 7 (the echo port). The segment establishes an initial sequence number of 544197796 and announces two connection parameters. First, it tells its peer that its MSS (maximum segment size) is 1,460 bytes. Second, it turns off window scaling (wscale 0). The timestamp option contains some timing information that TCP uses to calculate the round-trip time (RTT) of segments. TCP uses this information in its retransmission strategy. See [Stevens 1994] for the details of the MSS and window scale parameters and the timestamp option. The (DF) at the end of the line indicates that the DF flag in the IP header is set. This is the path MTU discovery mechanism that we discussed earlier.

Next, solaris ACKs the SYN and sends its own SYN and connection parameters. Notice that the acknowledgment number is 544197797, reflecting the fact that solaris is expecting byte 544197797 next. Finally, in line 3, laptop ACKs the SYN from solaris, and the connection is established.

It is also possible, but rare, for both peers to initiate a connection. This happens when they both send a SYN at roughly the same time. The SYNs cross in the network, as illustrated in Figure 2.18, and both peers respond with an ACK. This four-way handshake results in a single connection rather than the two that we might expect.

Figure 2.18. The Four-Way Handshake

If a host sends a SYN to a host for a port at which no application is listening, the receiving host will respond with an RST (a segment with the RST bit set). This tells the sending host that the connection cannot be established and that it should abandon the attempt.

That is, the RST indicates a hard error. If, for example, the sending host does not receive a SYN-ACK in response to its SYN after a given time, it will continue the attempt to connect by resending the SYN.

To illustrate this, we attempt to connect to a port where no application is listening:

laptop:~
$ nc -v linux 8000
linux [172.30.0.4] 8000 (?) : Connection refused

Then tcpdump shows linux responding to the SYN with an RST:

1   11:21:19.974218 laptop.1070 > linux.8000:
    S 1025154961:1025154961(0) win 57344
    <mss 1460,nop,wscale 0,nop,nop,timestamp 305005 0> (DF)
2   11:21:19.980602 linux.8000 > laptop.1070: R 0:0(0)
    ack 1025154962 win 0 (DF)

As we see in line 2, the response from linux has the RST bit set.

Connection Shutdown

After the two TCP peers have finished exchanging data, they enter the final phase of the session: connection teardown. When one side is finished transmitting data, it sends a segment with the FIN bit set. This acts as an EOF, telling the other side that TCP will send no more data. As illustrated in Figure 2.19, the other side will normally also send a FIN, completing the shutdown.

Figure 2.19. Connection Shutdown

Here is the end of the connection that we initiated to the echo server on solaris:

1  05:57:26.297609 laptop.1033 > solaris.echo: F 7:7(0) ack 7
   win 57920 <nop,nop,timestamp 77440 1559954580> (DF)
2  05:57:26.300517 solaris.echo > laptop.1033: . ack 8
   win 24616 <nop,nop,timestamp 1559955131 77440> (DF)
3  05:57:26.322748 solaris.echo > laptop.1033: F 7:7(0) ack 8
   win 24616 <nop,nop,timestamp 1559955131 77440> (DF)
4  05:57:26.322930 laptop.1033 > solaris.echo: . ack 8
   win 57920 <nop,nop,timestamp 77443 1559955131> (DF)

The FIN segments are in lines 1 and 3; the ACKs for them, in lines 2 and 4.

It's also possible for one side to close and the other to continue to send data. For example, the client could make a request of the server and then close its half of the connection to indicate that it's through making requests. The server would not close its side of the connection until it had finished responding to the client. This is illustrated in Figure 2.20. See Tip 16 of ETCP for more information on the halfclose operation and how it can be used in the so-called orderly release operation.

Figure 2.20. A Halfclose

Previous Page
Next Page


Section 2.8. ICMP

2.8. ICMP

The Internet Control Message Protocol (ICMP) is used to carry error and control messages. For example, if a router decrements an IP datagram's TTL to 0, it will send an ICMP error message back to the sending host, informing it that the datagram was dropped due to an exceeded lifetime. Another common example is the ICMP echo request and echo reply control messages, which are used by the ping utility to test connectivity between hosts.

Although ICMP is usually considered to be a network-layer protocol, ICMP messages are carried in IP datagrams and have their own encapsulation, as shown in Figure 2.21. The specification for ICMP is RFC 777 [Postel 1981].

Figure 2.21. ICMP Message Encapsulation in an IP Datagram

[View full size image]

ICMP Message Formats

Figure 2.22 shows the format of an ICMP message.

Figure 2.22. The General ICMP Header

[View full size image]

The type and code fields indicate the ICMP message type and subtype. Figure 2.24 lists the values for these fields.

The checksum field contains a normal IP checksum of the entire ICMP message. Recall that the IP checksum covers only the IP header, so ICMP must provide its own.

We will use the ping utility in many of our examples, so it is worthwhile taking a look at the ICMP echo request and reply messages in greater detail.

Figure 2.23 shows an ICMP echo request or reply message. Under UNIX, the identification field is usually the pid of the ping process sending the echo requests. This identification field is used to tie the echo replies back to the process that sent the echo request. As we have seen, the upper-layer protocols use ports to route data to the appropriate process, but because ICMP runs in the network-layer and doesn't have ports, it must use the identification field.

Figure 2.23. A ping Packet

[View full size image]

Figure 2.24. ICMP Message Types

Type

Code

Description

0

0

echo reply

3

destination unreachable

0

network unreachable

1

host unreachable

2

protocol unreachable

3

port unreachable

4

fragmentation required but DF bit set

5

source route failed

6

destination network unknown

7

destination host unknown

8

source host isolated

9

communication with destination network administratively prohibited

10

communication with destination host administratively prohibited

11

network unreachable for TOS

12

host unreachable for TOS

13

communication administratively prohibited

14

host precedence violation

15

precedence cutoff in effect

4

0

source quench

5

redirect

0

redirect for network

1

redirect for host

2

redirect for TOS and network

3

redirect for TOS and host

6

0

alternate host address

8

0

echo request

9

0

router advertisement

10

0

router solicitation

11

time exceeded

0

TTL is 0 during transit

1

TTL is 0 during reassembly

12

parameter problem

0

IP header bad

1

required option missing

13

0

timestamp request

14

0

timestamp reply

15

0

information request

16

0

information reply

17

0

address mask request

18

0

address mask reply

Here is a tcpdump of a single ping to host linux:

1   17:07:49.959527 laptop > linux: icmp: echo request
1.1    4500 0054 B0f60 0000 4001 12fd ac1e 000c    E..T.'..@.......
1.2    ac1e 0004 0800 c237 2308 0000 a504 1b3f    .......7#......?
1.3    5979 0e00 0809 0a0b 0c0d 0e0f 1011 1213    Yy..............
1.4    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223    .............!"#
1.5    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233    $%&'()*+,-./0123
1.6 3435 3637                                      4567
2    17:07:49.995696 linux > laptop: icmp: echo reply
2.1    4500 0054 2778 0000 4001 fae4 ac1e 0004    E..T'x..@.......
2.2    ac1e 000c 0000 ca37 2308 0000 a504 1b3f    .......7#......?
2.3    5979 0e00 0809 0a0b 0c0d 0e0f 1011 1213    Yy..............
2.4    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223    .............!"#
2.5    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233    $%&'()*+,-./0123
2.6    3435 3637                                      4567

The first 20 bytes in each datagram are the IP header. The ICMP messages follow the IP headers and are set in boldface. Notice that the echo request has a type of 0 and that the echo reply has a type of 8, as expected. The data portion of the message depends on what operating system the ping was run under and what options were specified for the ping invocation. In this case, the first 8 bytes are a timestamp, and each byte of the remaining data is the offset from the beginning of the data.

ICMP Error Messages

As we saw in Figure 2.24, ICMP messages can either be informational, such as the echo request/reply messages, or they can be error messages. The error messages follow the format shown in Figure 2.25: The type and code fields indicate the error, and the message-specific data is a copy of the IP header, including options, and at least the first 8 bytes of the upper-layer protocol header.

Figure 2.25. An ICMP Error Message

[View full size image]

We can see an example of an ICMP error message by sending a UDP datagram to a port with no application listening. The destination host will respond with a port-unreachable message as shown next. On laptop, we use netcat to send a datagram to port 6666 on bsd. Once the datagram is sent, netcat terminates:

laptop:~
$ nc -u bsd 6666
hello
laptop:~

We capture the result by running tcpdump on laptop:

1   06:28:53.089078 laptop.iad2 > bsd.6666: udp 6
1.1    4500 0022 003f 0000 4011 2243 ac1e 000c    E..".?..@."C....
1.2    ac1e 0001 0407 1a0a 000e 459b 6865 6c6c    ..........E.hell
1.3    6f0a                                       o.
2   06:28:53.091639 bsd > laptop: icmp: bsd udp port 6666 unreachable
2.1    4500 0038 0538 0000 4001 1d44 ac1e 0001   E..8.8..@..D....
2.2    ac1e 000c 0303 dedd 0000 0000 4500 0022   ............E.."
2.3    003f 0000 4011 2243 ac1e 000c ac1e 0001   .?..@."C........
2.4    0407 1a0a 000e 0000                       ........

We see the UDP datagram on lines 1.2 and 1.3 with its payload of hello\n. The ICMP error message is on line 2, with the ICMP header on line 2.2 set in boldface. Notice that the type and code are both 3. From Figure 2.24 we see that this is a port unreachable message. As shown on line 2, this message informs laptop that it sent a message to bsd on port 6666 but that no application was listening on that porthence the port was "unreachable."

In lines 2.2 and 2.3, we see a copy of the IP header from lines 1.1 and 1.2:

2.2    ac1e 000c 0303 dedd 0000 0000 4500 0022   ............E.."
2.3    003f 0000 4011 2243 ac1e 000c ac1e 0001   .?..@."C........

Notice that this header is an exact copy of the IP header from the UDP datagram.

Finally, on line 2.4, we see the 8 bytes of the UDP header:

2.4    0407 1a0a 000e 0000                ........

These bytes are how laptop knows that it was port 6666 (0x1a0a) that was unreachable, and that the source port of the sending application was 1031 (0x407).

Notice that bsd has set the UDP checksum field to 0 in the ICMP error message. This behavior is incorrect. If we run this experiment again but send the UDP datagram to solaris or linux instead of to bsd, the checksum field is correct. Indeed, both solaris and linux return the entire UDP datagram, showing that exactly what gets returned in an ICMP error message depends very much on the implementation.


Section 2.9. NAT and Private IP Addresses

2.9. NAT and Private IP Addresses

RFC 1918 [Rekhter, Moskowitz, Karrenberg et al. 1996] specifies that certain IP addresses are private. That is, that routers should not forward them outside the organization that is using them. The original idea was that enterprises that had no need to connect to the Internet or that needed only limited connectivity to the Internet through application gateways could use the private address space rather than obtain, and waste, globally routable addresses. Figure 2.26 lists the private address blocks and their address ranges.

Figure 2.26. RFC 1918 Private Addresses

Address Block

Range

10.0.0.0/8

10.0.0.110.255.255.255

172.16.0.0/12

172.16.0.0172.31.255.255

192.168.0.0/16

192.168.0.0192.168.255.255

If an organization is never going to connect its network to the Internet, it doesn't matter what addresses it uses, of course. Before RFC 1918, it was common for such organizations to arbitrarily choose an address block and use it. Suppose, however, that such an organization decides to add a mail gateway that is connected to both the private network and the Internet, so as to provide email services to the hosts on the private network.

Figure 2.27 shows an example of this for an organization that arbitrarily chose to number the hosts in its private network with addresses from the 18.0.0.0/8 block. As shown in the figure, the mail gateway has its internalto the private networkaddress set to 18.0.0.254 and is connected to the Internet through the globally routable address 96.29.5.15. Hosts inside the private network send their outgoing email to and receive their incoming email from the mail gateway.

Figure 2.27. A Private Network with a Mail Gateway

[View full size image]

Now suppose that someone in the organization wants to send email to a user at MIT. This creates a problem because MIT is the owner of the 18.0.0.0/8 address block, and the mail gateway will try to send the mail back into the private network rather than on to the mit.edu domain. Note how this problem disappears if the organization uses one of the private address blocks instead.

If that were all there was to private addresses, they would have remained a little-known backwater, especially today when almost every network that doesn't need to be completely isolated from the Internet enjoys full connectivity. When combined with network address translation (NAT), private addresses become a useful tool for conserving Internet addresses and for providing an amount of independence from any particular Internet service provider (ISP).

Before we can understand how this works, we have to know a little about network address translation. NAT is typically deployed on routers at the edge of an organization's network. If we replace the mail gateway in Figure 2.27 with a NAT-enabled router and renumber the private network with one of the private address blocks10.0.0.0/8, saywe get Figure 2.28. To understand why we need NAT, let's look again at what happens when a host in the private network10.0.0.1, saysends an email to someone at MIT. The MIT mail server is at 18.7.7.76, so the IP datagrams from our user on the private network to MIT will have a source address of 10.0.0.1 and a destination address of 18.7.7.76. This datagram could be delivered as it stands, but MIT's mail server will not be able to respond, because the 10.0.0.1 address is not routable.

Figure 2.28. A Private Network with a NAT-Enabled Router

[View full size image]

To be more precise, the datagram could be delivered in principle. Many routers and mail servers are configured to ignore traffic from private addresses as a way of avoiding denial-of-service (DOS) attacks and unsolicited email (Spam).

Therefore, before leaving the private network, the datagram must have its source address changed so that return datagrams can find their way back.

NAT can operate in three modes:

  1. In static mode, every host in the private-network that has access to the Internet has a corresponding public address. Thus, NAT need merely perform a one-to-one mapping from the private address to the public address and replace the source address with the public address.

  2. In pooled mode, hosts in the private network can use a pool of public addresses. For example, a pool of 32 public addresses might be available for 300 hosts in the private network. When a host in the private network begins a conversation with a remote peer, one of the public addresses from the pool is temporarily assigned to the host until the conversation is finished. If all the pool addresses are in use, no other hosts will be able to communicate outside the private network until one of the public addresses becomes free.

  3. In port address translation (PAT), the most common mode for NAT, there is usually only a single public address that all the hosts in the private network share, but the source port of the outgoing datagram is changed to a unique value that is used to associate return datagrams with the originating private address.

To get a better view of how PAT operates, let's drill down into the private network of Figure 2.28, as shown in Figure 2.29.

Figure 2.29. Part of a Private Network Using NAT

We once again suppose that host 1 wants to establish a connection with the MIT email server at 18.7.7.76 and that it uses the source port 2443.

Figure 2.30 shows the progress of the IP datagramcontaining the TCP SYN segment for the connection to MIT's mail serveras it leaves host 1, prior to having NAT applied, and after it leaves the router, which applied NAT.

Figure 2.30. An Outbound Datagram Before and After NAT

[View full size image]

As expected, the datagram has a nonroutable source address of 10.0.0.1 and a source port of 2443 as it leaves host 1. After having had the router apply NAT, the datagram has a source address of 96.29.5.15 and a source port of 5420.

MIT's mail server will see a connection request from a host at 96.29.5.15.5420, and will reply to the same address and port.

When there is a need to specify the port as well as the address in a TCP or UDP setting, it is common and convenient to write the port as a fifth number at the end of the address. Thus, 96.29.5.15.5420 means that the datagram has a source address of 96.29.5.15 and a source port of 5420.

We show the return datagram in Figure 2.31. Notice that as expected, the datagram arrives at the router with a destination of 96.29.5.15.5420 and a source address and port of MIT's mail server. The router looks up the 96.29.5.15.5420 in its PAT state table and discovers that the datagram should be sent to 10.0.0.1.2443. The left side of Figure 2.31 shows the datagram after the router has applied NAT.

Figure 2.31. An Inbound Datagram Before and After NAT

[View full size image]

If another host on the private network, say host 2 at 10.0.0.2, decided to send email to MIT at the same time as host 1, NAT would also map host 2's source address to 96.29.5.15 but would use a different source port, say 7322. Then when a return packet arrives addressed to 96.29.5.15.7322, NAT would know from the destination port number that the packet should be forwarded to 10.0.0.2.

The advantages of NAT are immediately clear. First, it saves IP address space by requiring only a single globally routable IP address for the entire private network. Second, it helps with router table growth by requiring only a single, or at most a few, router entries for the network. Third, it allows the organization to assign private addresses to all the computers in its network and to translate those addresses to public addresses at the edge of the network, where it connects to the outside world. Thus, the organization has a measure of independence from its ISP. If the ISP institutes policies that the organization finds unacceptable or if the organization is able to negotiate a more favorable contract with another provider, it need merely change its NAT rules, and won't have to worry about renumbering all the hosts within the network. Finally, NAT can result in cost savings by allowing the organization to obtain only a single globally routable IP address from its ISP. This last advantage makes NAT especially popular with home and small-business networks.

Despite these advantages, NAT is almost universally reviled among networking experts. Although we discussed NAT as if it involved a simple remapping of the internal host's address, a closer look will reveal that much more is involved. Let's consider what happens after NAT performs its translation. First, when the host's IP address is changed in the IP header, the IP header checksum is invalidated and will have to be recalculated. Next, NAT will have to look in the IP datagram to see what type of data it's carrying; if it's a TCP or UDP packet, that checksum is also invalidated, because of the pseudoheader.

Requiring a network-layer function, such as NAT, to look inside the IP datagram is called a layer violation. Recall that the ideal is for IP to consider the data that it's carrying as opaque. Once one layer must look at and change the data of another layer, we lose much of the benefit of layering that we discussed earlier.

This is only the beginning, though. Many application protocols, such as ftp [Reynolds and Postel 1985], require the use of more than one connection. In the case of ftp, for example, the client sends the server a PORT command asking the server to open a connection to the client at a given address and port. The address and port number are transmitted as ASCII data. Note that NAT must be aware of this for two reasons: first, it must remap the private IP address that the client sends the server; second, it must remember, and possibly remap, the port number so that it won't interfere with a previously NAT-assigned port and so that NAT will know how to map the IP/port pair back to the private network when the server responds.

This means that NAT must look inside the TCP packet to see whether it's carrying an ftp PORT command. If it is, NAT must change the address and port in that command. This invalidates the TCP checksum, of course, but we already have to recalculate that because of the pseudoheader. Note, though, that the size of the segment may changemapping 10.0.0.1 to 96.29.5.15 adds 2 bytes, for example. If the client believes that the last byte it sent has sequence number n, the serverassuming, as in the example, that 2 bytes were addedwill believe that the last byte has sequence number n + 2, and will send an ACK specifying n + 3 as the next expected byte. Thus, NAT will have to change the ACK back to n + 1. Furthermore, NAT will have to remember and correct this discrepancy in sequence numbers for the remainder of the connection.

FTP passive mode was introduced to deal with these problems. In passive mode, the client initiates both the control and data connections, so there is no need for NAT to look inside the data packet to find the address and port of the connection. When the client wants to open a data connection, it sends the server a PASV command, which requests that the server start listening for the data connection on a port of its choice. The server responds on the control connection with the port that it will listen on.

NAT can and does deal with ftp and a few other well-known protocols but will certainly break any user-written protocols that depend on passing address or port information in the data stream. For our purposes, NAT, and especially PAT, have fatal flaws. As we shall see, certain IPsec modes will detect any changes in the source or destination IP addresses and drop the datagram if a change is detected. The most common IPsec protocol, the Encapsulating Security Payload protocol (ESP), encrypts the entire TCP or UDP header, so that the ports numbers will not even be visible. Thus, PAT cannot be used with IPsec.

We will come back to these problems in Part 3 when we discuss IPsec and NAT traversal. The operation of NAT, its strengths, and its weaknesses are discussed in RFC 1631 [Egevang and Francis 1994]. NAT terminology is defined and discussed in RFC 2663 [Srisuresh and Holdrege 1999].


Section 2.10. PPP

2.10. PPP

The Point-to-Point Protocol (PPP) is an interface-layer protocol. We usually think of it as the protocol used to carry IP datagrams over serial lines in dial-up connections to an ISP, but as we shall see, PPP can also carry IP over other media. For example, PPP is commonly used to carry data over Ethernet, T1/E1 connections, and ATM. In Chapter 4 and Part 2, we will see that PPP is frequently used in building tunnels. Because of its use in tunneling and because we will use it ourselves in some of the tunnels we build, it is worthwhile spending a little time to understand the rudiments of the protocol.

PPP evolved from two other networking technologies: serial line IP (SLIP) and the High-Level Data Link Control (HDLC) protocol, as shown in Figure 2.32.

Figure 2.32. The PPP Family Tree

SLIP is an extremely simple protocol used to frame IP datagrams on serial lines. It is defined in RFC 1055 [Romkey 1988], which also provides sample C code for sending and receiving IP packets assuming the primitives send_char() and recv_char(), which send and receive a single character over a serial line. The design is straightforward: A special END character (0xc0) is used to begin and end each IP datagram. Any END characters in the data are replaced with the sequence 0xdb 0xdc, where the 0xdb is called the SLIP ESC character. Any SLIP ESC characters are replaced by the sequence 0xdb 0xdd.

Note that the SLIP ESC character, 0xdb, is different from the ASCII ESC character, 0x1b.

SLIP provides no addressing or error detection and can carry only IP datagrams. It also has no built-in compression capabilities, but Van Jacobson's VJ header compression is often used in conjunction with it to compress the TCP and IP headers in TCP segments. VJ compression, which is defined in RFC 1144 [Jacobson 1990], can also be used in PPP connections.

The HDLC protocol was originally developed for use on synchronous leased lines. It specifies both packet-framing formats and a method of transmitting a bit stream on the synchronous digital link that provides the physical medium. The basic HDLC packet is shown in Figure 2.33.

Figure 2.33. HDLC Packet Format

[View full size image]

The address field carries the station ID in multidrop lines. Because PPP is a point-to-point protocol, this field is not necessary and is set to 0xff. The control field specifies the type of data in the information field. For PPP, the control field is always set to 0x03. IP datagrams and other data are carried in the information field. The frame check sequence (FCS) field is a standard 16- or 32-bit cyclic redundancy check (CRC).

On synchronous lines, each HDLC frame is preceded by the 8-bit sequence 01111110. This so-called flag is used to synchronize the receiver and tell it that another frame is coming. The synchronous wire protocol ensures that no more than five consecutive 1-bits will appear in the data, so the flag is unique. PPP on asynchronous media uses the same idea: Each PPP frame is terminated with a flag byte of 0x7e. Although not strictly required, most PPP implementations will also start the frame with a flag byte to help prevent interframe line noise, particularly on asynchronous serial lines, from corrupting the following frame.

As with SLIP, a PPP ESC byte (0x7d) is used to escape flag bytes, PPP ESC bytes, and other bytes, such as the ASCII control bytes, that the PPP peers may negotiate. The effect of a PPP ESC is to exclusive-OR 0x20 with the byte being escaped. Thus, a 0x7e (flag) byte in the data will be transmitted as the sequence 0x7d, 0x5e. Similarly, a PPP ESC byte in the data will be transmitted as the sequence 0x7d, 0x5d. This process is illustrated in Figure 2.34, which shows a PPP packet before and after the data is framed and escaped.

Figure 2.34. A PPP Packet Before and After Framing and Escaping

[View full size image]

The negotiation of a PPP link has three main phases.

  1. The Link Control Protocol (LCP) establishes the basic parameters for the transmission of data over the physical link. Parameters, such as the maximum receive unit (MRU), bytes needing escaping, header compression options, type of CRC to use, authentication protocols, and padding requirements are negotiated in this phase.

  2. The authentication phase identifies the peers to each other, using the protocol or protocols negotiated in the LCP phase. The authentication phase uses protocols such as the Password Authentication Protocol (PAP), the Challenge-Handshake Authentication Protocol (CHAP), and the Extensible Authentication Protocol (EAP) to authenticate the peers.

  3. The Network Control Protocol (NCP) phase negotiates parameters for one or more network protocols, such as IP, that the PPP link will carry. We are interested in using PPP to carry IP datagrams only, but it can also carry other protocols, such as AppleTalk and IPX. When the NCP phase is operating on behalf of IP, it negotiates parameters such as the IP addresses of the peers, domain name system (DNS) servers, and whether to perform VJ compression. Although not really network-layer protocols, the Compression Control Protocol (CCP) and Encryption Control Protocol (ECP) are also considered NCPs. As their names suggest, they are used to negotiate compression and encryption algorithms and their parameters.

The information field can contain IP datagrams or control information used during LCP, authentication, and NCP negotiation. The first 2 bytes of the information field, called the protocol field, indicate the type of data the information field is carrying, as shown in Figure 2.35. The format of the LCP and NCP data is defined in a series of RFCs, but [Carlson 2000] has an excellent discussion of this data and a thorough explanation of the working of PPP.

Figure 2.35. PPP Frame Formats

[View full size image]

Because PPP normally makes no use of the address and control fields, the peers can agree during LCP negotiations to omit them in non-LCP frames. Similarly, the peers can agree that they will compress the protocol field to a single byte whenever possible. If the most significant byte of the protocol field is odd, it is compressed; otherwise, the full protocol field is present. Being aware of these optimizations is important because we will see examples of them in our network traces later in the text.


Section 2.11. IPv6

2.11. IPv6

We have already seen how CIDR and NAT are being used as short-term solutions to the depletion of IPv4 addresses. The longer-term solution is a new version of IP: IP version 6 (IPv6). IPv6 improves on IPv4 in the following areas:

  • A larger address space. IPv6 increases the 32-bit addresses of IPv4 to 128 bits. The new addresses are explicitly hierarchical, which helps prevent router table growth. We'll discuss the IPv6 address structure shortly.

  • A simplified, fixed-sized header. The IPv6 header is considerably simplified. The number of fields has been reduced from 13 in IPv4 to 8 in IPv6. This simplified header allows routers to process IP datagrams more efficiently and therefore to obtain higher routing speeds.

  • Improved handling of IP options. Rather than include options in the IP header itself as IPv4 does, IPv6 has separate option headers. With one exception, intermediate routers need not examine these headers, again adding to routing speed.

  • Flow labels. The IPv6 header includes a 20-bit flow label that allows IP packets to be identified as belonging to a particular flow. This capability enables differentiated handling of a series of IP datagrams belonging to the same flow.

The IPv6 Address Model

IPv6 has three types of addresses:

  1. Unicast addresses. These addresses refer to a unique interface on a unique node. They serve the same function and are similar to the unicast addresses of IPv4.

  2. Anycast addresses. These addresses refer to a set of interfaces, usually on different nodes. A datagram sent to an anycast address is delivered to the nearest interface having that address, where "nearest" is determined by the routing protocols.

  3. Multicast addresses. Datagrams sent to a multicast address will be delivered to all interfaces having that address. Be aware that under IPv6, there are no broadcast addresses. The functions of the IPv4 broadcast address types are assumed by multicast addresses in IPv6.

Because IPv6 addresses are so long, we use a different notation to write them. The nominal textual representation is x1: x2: x3:x4: x5: x6: x7: x8, where each xi represents one of the eight 16-bit pieces of the address. Typical examples are

fe9c:ba78:0:0:0:400:33ac:20
2:0:0:0:204:faff:fe41:d630
0:0:0:0:0:0:0:1

As we see in the examples, we can simplify the addresses by not writing the leading 0s in each field. We can further simplify them by replacing the longest run of 0s with ::. Thus, we could write the three preceding examples as

fe9c:ba78::400:33ac:20
2::204:faff:fe41:d630
::1

The last address in the examples is the loopback address. It serves the same function as 127.0.0.1 does in IPv4.

The structure of a typical unicast address in shown in Figure 2.36.

Figure 2.36. An IPv6 Unicast Address

[View full size image]

The routing prefix corresponds to the IPv4 network ID. It is used to route datagrams to a particular network, or site in IPv6 terminology.

The subnet ID is used to identify individual segments, or links in IPv6 terminology. A site's internal routers can use this field to route datagrams to the proper link.

The interface ID is unique for each interface on the link and corresponds to the host ID in IPv4. This field is required to be 64 bits unless the address begins with the binary sequence 000.

The IPv6 addressing architecture is specified in RFC 3513 [Hinden and Deering 2003]. Specific aspects of addresses, such as the formation of the interface ID, are specified in a series of other RFCs referenced in RFC 3513.

The IPv6 Header

The IPv6 header, shown in Figure 2.37, is simpler than the IPv4 header. Because the header has a fixed size, there is no header-length field. Because IPv6 headers are not checksummed, there is no checksum field. Because fragmentation is handled with a separate extension header, there are no identification, fragment-offset, DF, or MF fields.

Figure 2.37. The IPv6 Header

[View full size image]

The version field identifies the datagram as a version 6 datagram. The version field is set to 6.

The traffic class and flow label fields are used to provide special handling for IP datagrams. The use of these fields is still experimental, and they will not play any role in this text.

The payload length field is the length of the datagram exclusive of the header. Because the header size is fixed at 40 bytes, the size of the entire datagram is implicitly known from this value. The payload length includes any extension headers present in the datagram.

The next header field is analogous to the protocol field in the IPv4 header. If the datagram has no extension headers, this field will specify an upper-layer protocol, such as TCP or UDP, or a network-layer protocol, such as ICMP. If the datagram does have extension headers, this field will specify the extension header immediately following the IP header.

The hop limit field is the same as the TTL field in IPv4. It is used to prevent IP datagrams from circulating in the network indefinitely.

The source and destination address fields contain the 128-bit addresses of the node originating the datagram and the node to which it is being sent. If a routing extension header is present, the destination address may not be that of the ultimate destination.

Because the IPv6 header is not checksummed, the use of a pseudoheader is even more important than in IPv4. The IPv6 pseudoheader is shown in Figure 2.38. As in IPv4, this pseudoheader is prepended to TCP and UDP packets for purposes of calculating the checksum only.

Figure 2.38. The IPv6 Pseudoheader

[View full size image]

IPv6 Extension Headers

In IPv6, optional network-layer information is encoded into separate data structures called extension headers. The IPv6 specification, RFC 2460 [Deering and Hinden 1998], lists six types of extension headers. Two of thesethe authentication header (AH) and the encapsulating security payload (ESP) headerare part of IPsec; we will discuss them in Part 3. The other four deal with hop-by-hop options, destination options, routing, and fragmentation.

Except for the hop-by-hop option header, no node except that specified in the destination address field need examine or deal with these headers in any way. Because the hop-by-hop extension header must immediately follow the IPv6 header, a router need merely look at the next header field in the IPv6 header to know whether or not it need concern itself with the extension headers. Currently, no hop-by-hop options are defined except for the padding options used by all the headers to align data on the appropriate boundary.

The router extension header plays a role similar to that of source routing in IPv4. This header allows the sender to specify a series of intermediate nodes through which the datagram must pass.

Fragmentation in IPv6 differs from that in IPv4. First, IPv6 datagrams are never fragmented by intermediate nodes; hence the lack of a DF bit. In IPv6, only the source host can fragment a datagram. This implies that path MTU discovery is mandatory in IPv6. Second, when a datagram is fragmented, the information about each fragment is in the fragmentation extension header. This header contains fragment-offset, MF bit, and identification fields, just as in IPv4.

The destination extension header is examined by the destination node or nodes. Like the hop-by-hop extension header, no nontrivial destination options are currently defined.

In addition to the fields necessary to perform their functions, each extension header has a next-header field. Nodes use this field to determine the meaning of the data following the extension header: another extension header, a network-layer protocol header, or a transport-layer protocol header. Figure 2.39 shows a typical IPv6 datagram with extension headers and a TCP segment.

Figure 2.39. An IPv6 Datagram

[View full size image]

The complete specification of IPv6 is spread among several RFCs. For further information, see <http://www.ietf.org/html.charters/ipv6-charter.html>, the Web site of the IETF (Internet Engineering Task Force) Working Group on IPv6.


Section 2.12. Routing

2.12. Routing

Later in the text, we will need some rudimentary information about routing protocols, so let's briefly review a few basics here. Our goal is not to examine any particular routing protocol in depth but merely to understand the various types of routing protocols and how they interoperate to provide routers with the information they need to choose the next hop for an incoming IP datagram. See [Comer 2000] for an excellent summary of routing and routing protocols. For detailed discussions of the algorithms, their strengths and weaknesses, and how they work, see [Huitema 2000] and [Perlman 2000].

As we've seen, hosts usually have routing (forwarding) tables that contain at most a few routes to specific networks or hosts, and a default route for all other traffic. Indeed, most hosts probably have only a default route, so that all traffic that is not bound to a destination on the same network is sent to a single router that forwards it on to its destination. Typically, the default route and any others a host might need are static; that is, they are set manually by the system administrator or user of the host.

In a small organization, the routers could be configured statically too, but it's obvious that this solution doesn't scale beyond a very small number of routers. That realization brings us to the central question of this section: How do the routers learn the routes they use to populate their routing tables? The obvious answer is that the routers exchange information about which networks they can reach, but that answer brings its own questions.

For example, if an organization has a router sitting on one of its networks, how many other routers should it exchange routes with? It's obviously impractical for the router to exchange routes with every other router on the Internet, so where do we draw the line? Let's consider an organization, such as an ISP, that manages a large number of networks. Figure 2.40 represents a small part of the total network topology of the organization.

Figure 2.40. Part of the Network Topology for a Large Organization

Suppose that a host on network 4 wants to send an IP datagram to a host on network 3. Notice that the datagram could take two possible paths: R4 [image] R2 [image] R3 and R4 [image] R5. R4 must have enough information to choose the best next hoppresumably, R5 in this case. In order to do this, R4 has to have at least a partial understanding of the topology of the network. Similarly, the other routers must understand the network topology well enough to choose the best path for datagrams. Router R1, for example, must have an entry in its routing table for each of the internal networks so that it can deliver datagrams coming in from the outside. To obtain this information, the internal routers exchange messages telling each other what networks they can reach and perhaps how many hops away each network is.

On the other hand, outside routers don't need to have any understanding of the organization's internal network topology. They need know only that datagrams destined for any of the organization's networks should be sent to R1. Thus, R1 is the only router that needs to exchange routes with outside routers. This leads us to the observation that routing information exchanged within an organization's networks is likely to be different from the routing information exchanged with outside routers. The information exchanged internally must reflect the network topology, whereas the information exchanged with outside routers need merely contain reachability data.

Autonomous Systems

As we've seen, internal and external routers need different types of routing information. The term autonomous system (AS) formalizes the notion of internal. An autonomous system is a collection of networks and routers under the control of a single authority. Each autonomous system is assigned a number by the Internet Assigned Numbers Authority (IANA). Examples of autonomous systems in the United States are Harvard (11), Earthlink (3703), and Novell (3680).

For our purposes, the importance of autonomous systems is that the authority in charge of each system is totally responsible for its internal topology and routing. Each autonomous system chooses one or more routing protocols and any policies that apply to those protocols. To an outsider, an autonomous system appears, in the words of RFC 1772 [Rekhter and Gross 1995], "to have a single coherent interior routing plan and presents a consistent picture of which destinations are reachable through it." As suggested in Figure 2.40, each autonomous system has one or more gateways, called border routers, that exchange traffic with other autonomous systems.

Autonomous systems exchange traffic at network access points (NAPs), which are facilities where several autonomous systems maintain border routers on a common network so that they can exchange traffic with one another. Examples of NAPs are MAE-East (Washington DC), Chicago NAP, LINX (London), MAE-Paris, CATNIX (Barcelona), and several others throughout the United States and the world. In addition, some ISPs have private peering agreements that take place outside of NAPs.

A routing protocol that runs within an autonomous system is called an interior gateway protocol (IGP); one that exchanges routes between autonomous systems is called an exterior gateway protocol (EGP). The next two subsections briefly examine each type of protocol.

Interior Gateway Protocols

Autonomous systems use interior gateway protocols to enable internal routers to optimize their forwarding decisions by learning the best next hop for IP datagrams. In order to make optimum decisions, each router must understand the network topology at least to the extent that it can assign a cost to each next hop. For example, let us assume that the routers in Figure 2.40 measure the cost of a route by the number of hops a datagram must take to reach its final destination. If router R4 needs to forward a datagram to network 3, it would choose the path through R5 with a cost of 2 rather than the path through routers R2 and R3 with a cost of 3. Note that R4 needn't understand the exact route the datagram will take after the next hop, merely that one next hop will yield a lower-cost route than the other.

There are two main classes of IGPs: distance-vector protocols and link-state protocols. In distance-vector protocols, as exemplified by the Routing Information Protocol (RIP) [Hedrick 1988] and RIP2 [Malkin 1994], each router sends its neighboring routers a copy of its routing table, which includes the cost to reach each destination network.

More precisely, each router sends its neighbors certain columns from its routing table. There is no need, for example, to send the link that a certain network is reachable through; the network and cost to reach it are sufficient.

In this way, each router builds up a routing table that contains the next hop and cost to reach each network.

In Figure 2.40, for example, R5 would inform R3 and R4 that it can reach network 5 in one hop. R3 would enter a route to network 5 in its routing table with a next hop of R5 and a cost of 2 and then inform R1 of its routes. Router R1 would make an entry in its routing table for network 5 with a next hop of R2 and a cost of 3. These routers may learn better routes to network 5 as they hear from other routers, so these initial entries may be replaced as the routing protocol converges to a final state. Each time a router updates its forwarding table, it must send the updated table to its neighbors.

Several problems with distance-vector protocols limit their use to relatively small networks. First, because each router sends its neighbors information proportional to the size of its routing table, the traffic generated by the routing protocol itself can become significant.

Second, distance-vector protocols can be slow to converge after a network changesuppose that the direct line between R4 and R5 of Figure 2.40 goes down, for instanceand it's easy for routing loops to develop unless special care is taken to prevent them. Finally, each router depends on its neighbors to calculate part of its routing table. In this sense, the calculation of each router's forwarding table is a distributed process, and if one router makes an error in calculating its routes, it can affect the routing tables of all the routers.

More formally, each router takes part in a distributed Bellman-Ford algorithm calculation [Ford and Fulkerson 1962] to arrive at a final common routing table.

Link-state, or shortest path first, protocols take a different approach. Each router broadcasts a list of currently reachable directly connected routers and networks and the cost of reaching them; this process is called flooding. Note that the amount of information that each router transmits is proportional to the number of interfaces on the router, not the size of its routing table.

Each router then uses this information to build a directed graph representing the network. For example, with the network of Figure 2.40, such a graph would be similar to Figure 2.41.

Figure 2.41. A Graph of the Network in Figure 2.40

Each router can now independently calculate the shortest path to each of the other nodes in the graph, using Dijkstra's algorithm [Dijkstra 1959] or a similar method.

By "shortest path" we mean the path of least cost. Several metrics are possible for measuring cost. We could use hops, as with RIP, or some other measure such as delay, link speed, monetary cost, or reliability.

The most common link-state routing protocol is the Open Shortest Path First (OSPF) protocol [Moy 1998a, Moy 1998b]. Because it scales better than distance-vector protocols and can divide an autonomous system into semi-independent areas that operate within the autonomous system, much like the autonomous systems operate within the greater Internet, OSPF is the IGP of choice for all but the smallest networks. OSPF has other optimizations and capabilities as well. See the preceding references for complete details.

The IS-IS (intermediate system to intermediate system) protocol, another link-state routing protocol, is very similar to OSPF but for historical reasons is used primarily by ISPs, whereas OSPF is used primarily on customer networks. For more information on IS-IS and how it differs from OSPF, see [Perlman 2000].

A third choice for routing within autonomous systems, ix autonomous~system is the Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a Cisco proprietary protocol in the distance-vector family. Although similar to RIP, EIGRP has many improvements that help prevent loops from forming and avoids some of the other problems with distance-vector protocols while maintaining much of their simplicity.

Exterior Gateway Protocols

In the history of the Internet, several exterior gateway protocols have been used. Given the architecture of the Internet today, however, virtually all border routers use the Border Gateway Protocol (BGP) [Rekhter and Li 1995].

In the early days of the Internet, there was a backbone network to which the other networks connected in a manner similar to the way hosts connect to an Ethernet backbone today. With that topology, simpler exterior routing protocols, such as the Exterior Gateway Protocol (EGP), were used. Today's topology of autonomous systems exchanging traffic at a series of NAPs or through private peerings requires a more complicated protocol.

BGP views the Internet as a graph where the nodes are the autonomous systems and the edges are the links between them. The internal topology of an external AS plays no role in BGP. Indeed, an AS is generally ignorant of a neighboring autonomous system's internal structure except for the networks that it contains.

As a first approximation, border routers use BGP to tell a peer border router in a neighboring AS what networks it can reach. These networks may be interior networksthose belonging to the router's ASor they may be networks belonging to another AS that the border router knows how to reach. When a border router receives routes from a peer, it redistributes them to the interior routers, using whatever IGP the AS is running.

Our first-approximation description covers the simplest case of an autonomous system having a single border router. In this case, the border router has no real choices to make. It collects reachability information from its external peers and distributes it to the internal routers. Because it is participating in the IGP of the AS, the border router knows what internal networks are reachable, so it informs its external peers of these networks so that external hosts can reach them.

It may be that the manager of the AS wants to keep some or all of the internal networks private. In this case, the border router can be configured not to advertise them to its external peers. Likewise, it is conceivable that the manager may wish to prohibit internal access to certain external networks. Again, the border router can be configured to ignore these routes and not distribute them to the internal routers. Other than these exceptional cases, the single border router merely exchanges reachability information with its external peers.

Now let's consider a slightly more complicated case. Figure 2.42 shows parts of three autonomous systems, each having two border routers. Notice that from the point of view of a router within AS1, network N3 in AS3 is reachable through both routers B1 and B2. From the figure, it appears that, all links being equal, the route through B2 is preferable. Thus, only router B2's route to N3 should be advertised to the internal routers.

Figure 2.42. Parts of Three Autonomous Systems

[View full size image]

We might think that both B1 and B2 could advertise their routes but with different metrics. The problem is that BGP doesn't have metrics in the sense that RIP and OSPF do. It's not difficult to see why: Different autonomous systems can use different metrics within their networks, and it may not make sense to compare them. For example, suppose that AS2 uses hop count as a metric but that AS3 uses link speed. What metric should B3 report to B1 for network N3? Similarly, how could an internal router, such as I1, compare the metrics it got from B1 and B2?

This raises the question of how a border router knows whether to advertise a route it has learned from one of its peers. In our example from Figure 2.42, B1 should not advertise a route to network N3, even though N3 is reachable through B1. The answer is that the internal border routers talk to each other.

Ideally, the BGP instance on each border router establishes a TCP connection with every other border router in the autonomous system so that the connections between the routers form a full mesh. This may not be practical for very large autonomous systems, so sometimes the AS manager will configure the routers to form only a partial mesh. These connections are logical TCP connections, not necessarily direct physical connections. Indeed, the border routers are likely to be on separate networks in different, widely dispersed geographical locations.

BGP is an example of a path-vector protocol. Each BGP route advertisement includes additional information about the route, the most important of which is a list of the autonomous systems that must be traversed to reach the destination. This list of autonomous systems is referred to as a path. When BGP receives path information to a network in an external AS, it chooses the best path to that destination among all the paths that it knows about. This best path is distributed to the other internal BGP routers.

The factors considered in choosing a best path are determined by BGP configuration. RFC 1772 [Rekhter and Gross 1995] lists such possible considerations as

  • AS countthe number of autonomous systems in the path

  • Policy considerationsa decision by the AS manager not to use routes through a certain AS or a preference for one AS to another

  • Path originwhere the route was learned from: BGP, an IGP router, or another EGP

  • AS path subsetsgenerally, preference for a path that is a subset of another

  • Link dynamicspreference for stable paths over unstable paths

The other internal BGP routers do the same thing, of course, so that at the end of this process, each BGP router will have a list of candidate paths to the destination. Each router then calculates the most-preferred path, which is distributed to the IGP routers and the external BGP routers. All internal BGP routers perform the same best-path calculation, so they will agree on the preferred path to the destination, and will advertise the same path.


Section 2.13. Summary

2.13. Summary

In this chapter, we have made a quick tour of the TCP/IP protocols and their data formats. We began by discussing layering and encapsulation and their roles in networking architecture. These conceptual tools allow us to divide the network's functions into discrete sets, or layers, that can be more easily understood in isolation. Communication between layers follows a well-defined API (application programming interface) that allows changes to one layer without affecting the others.

In our examination of IP addressing, we saw that the classical division of addresses into five classes leads to the growth of routing tables and the depletion of globally routable addresses. CIDR helps solve these problems by generalizing classful addressing to allow fine-grained control over the boundary between the network and host IDs in the address. Although classful addressing is still mandated by the IETF as the standard, virtually all addressing uses CIDR.

Next we studied the IP, TCP, UDP, and ICMP protocols. These protocols make up the core of the TCP/IP suite and are the foundation on which applications are built. While discussing these protocols, we studied their operation on the wire by examining tcpdump traces. Although examining the protocols at this level may seem like overkill in an overview, it helps us to develop the skill of reading tcpdump output and dissecting network packets. We will use these skills often as we discuss tunneling and VPNs in the rest of the text.

We continued our study of addressing by considering RFC 1918 private addresses and NAT. Although NAT has several undesirable effects, it is a useful and popular tool to conserve IP global addresses, foster independence from any particular ISP, and reduce costs by allowing several hosts to share the same global IP address. The combination of NAT and CIDR is providing a short-term solution to the IP address depletion problem until the long-term solution, IPv6, can be deployed.

PPP is, of course, just another interface layer protocol like Ethernet or Token Ring, but because it is often used as a vehicle for IP datagrams in tunnels, we made a cursory examination of it. We usually think of PPP as a protocol running on serial links, but it can run over a variety of media. PPP combines the simple point-to-point serial-link protocol of SLIP with the framing and some of the functionality of HDLC.

Next, we examined IPv6. Although we will not dwell much on IPv6, it is important to understand some of its features. This is particularly true because IPsec, which we discuss in Part 3, is part of IPv6.

Finally, we briefly discussed routing. We introduced the notion of autonomous systems and noted that the interior gateway protocols used within an AS differ from the exterior gateways protocols used among autonomous systems.


Exercises

2.1 | Consider a host that supports IP and other networking protocols, such as IPX or AppleTalk. Each of these protocols will have its own stack. Suppose that the protocols all use the same Ethernet interface. Investigate the Ethernet frame format and discover how the operating system is able to tell which stack it should deliver the data to.
2.2 | What is the identification number of the IP datagram in Figure 2.4?
2.3 | How can IP differentiate the first fragment of a fragmented IP datagram, which will have a fragment offset of 0, from an unfragmented datagram?
2.4 | IP does not reassemble a fragmented datagram until it has received all the fragments. How does IP know when it has received all the fragments? Remember that the fragments can arrive out of order.
2.5 | We said that UDP checksums are optional and that a sender signals the receiver that it is not using a checksum by setting the checksum field in the UDP header to 0. How can a receiver tell the difference between "no checksum" and a UDP datagram that happens to checksum to 0? Hint: Internet checksums are calculated using ones-complement arithmetic.
2.6 | Ignoring any implementation-specific or MTU restrictions, what is the maximum amount of data that can be transmitted in a UDP datagram?
2.7 | Suppose that hosts A and B have established a TCP connection but are not exchanging data, and that host A crashes and reboots. Is there still a connection? Do hosts A and B agree with your answer?
2.8 | What will the routing table for host 4 of Figure 2.9 look like?
2.9 | We said that only the hop-by-hop extension header in IPv6 needs to be examined by each router. Why doesn't the routing header need to be examined by each router also?
2.10 | How do the IGP distance-vector protocols differ from the BGP path-vector protocol?
2.11 | BGP views the Internet abstractly as a graph, with the nodes being autonomous systems. This suggests that a link-state protocol might be an appropriate way of introducing more precise metrics into EGP routing. What problems do you think a link-state protocol might encounter?
2.12 | As with any other routing protocol, BGP must take steps to ensure that routing loops do not develop. How can BGP use the path information associated with an advertised network to avoid such loops?


Chapter 3. Cryptography Overview

    Section 3.1. Introduction

    Section 3.2. Symmetric Ciphers

    Section 3.3. Asymmetric Ciphers

    Section 3.4. Cryptographic Hash Functions, MACs, and HMACs

    Section 3.5. Digital Signatures

    Section 3.6. Certificates

    Section 3.7. Summary

    Exercises


Section 3.1. Introduction

3.1. Introduction

Cryptography is a vast and difficult field that we cannot hope to cover in this book. Nevertheless, an understanding of the basics and an appreciation of some of the subtleties of cryptography are necessary for an understanding of what is to follow. Fortunately, just as with TCP/IP, several excellent texts are available for those who wish to delve deeper into its mysteriessee [Schneier 1996], [Ferguson and Schneier 2003], and [Menezes, Oorschot, and Vanstone 1996], for example.

In this chapter, we are concerned mainly with three major subjects:

  1. Encryption/decryption

  2. Message authentication codes

  3. Digital signatures

Along the way, we shall also examine Diffie-Hellman key exchange and the use of certificates for authentication and key exchange.

As we shall see, there are two main types of ciphers used for encryption: symmetric and asymmetric. These two types generally serve different purposes but work together to provide a total solution. The symmetric ciphers are again divided into two main classes: block and stream. Both of these classes have their strengths and weaknesses, and we shall examine examples of each as we go along.

This chapter is more mathematical than the others, so some readers may want to skip the details and take in just the major points. On the other hand, the chapter covers the bare minimum needed for a reasonable understanding of modern cryptography, so interested readers may want to consult the references cited in the chapter.


Section 3.2. Symmetric Ciphers

3.2. Symmetric Ciphers

Symmetric ciphers get their name from the fact that the same key is used for both encryption and decryption. A trivialand horribly insecureexample is a cipher that merely performs an exclusive-OR ( [image]) of each byte of a message with a corresponding byte of the key (see Figure A.1). For example, if our key is 0123, we would encrypt and decrypt the message trivial as shown in Figure 3.1.

Figure 3.1. A Trivial Symmetric Cipher

ASCII

HEX

Plaintext

trivial

74 72 69 76 69 61 6c

Key

0123012

30 31 32 33 30 31 32

Plaintext [image] key = ciphertext

DC[EYP^

44 43 5b 45 59 50 5e

Key

0123012

30 31 32 33 30 31 31

Ciphertext [image] key = plaintext

trivial

74 72 69 76 69 61 6c

In this case, the decryption operation (exclusive-OR) as well as the key are the same as for encryption, but in many symmetric ciphers, only the key is the same.

Interestingly, even though this cipher is trivial to break (see [Dawson and Nielsen 1996] and Section 1.4 of [Schneier 1996]), it is almost identical to the only known provably unbreakable cipher: the one-time pad. The crucial difference is that with the one-time pad, the key is never repeated. This implies, of course, that the key must be at least as long as the message and that each message must have its own key.

Stream Ciphers

Our trivial cipher is an example of a stream cipher. The distinguishing characteristic of stream ciphers is that they operate on the plaintext one character at a time, and that the same character does not necessarily encrypt to the same cipher text each time it is encountered. We can see an example of this last phenomenon in Figure 3.1, where the first i of trivial encrypts to [ and the second i encrypts to Y.

When we say character in the preceding definition, we are deliberately speaking loosely. Stream ciphers can operate on individual bits, on bytes, or even on 32-bit "characters." The point is that stream ciphers operate on relatively small units of information and may encrypt a given character differently at different places in the text stream.

Probably the most common stream cipherowing to its use in SSL (Secure Sockets Layer), discussed in Chapter 6is RC4. The idea behind RC4 is to generate a sequence of pseudorandom bytes, called the key stream, that can be exclusive-ORed into the plaintext, as we did in Figure 3.1. Because the sequence of bytes in the key stream does not repeat for a very long time, it is not vulnerable to the easy attacks that a cipher based on the repeated exclusive-ORing of a key into the plaintext is. Because that sequence is not truly random, it does not offer the perfect security of a one-time pad.

RC4 was invented in 1987 by Ron Rivest at RSA Data Security, Inc. The RC4 algorithm is proprietary to RSA Security, and the details of its operation have never been publicly revealed. What we are about to describe is a reverse engineered version sometimes called alleged RC4. Independent observers with access to the licensed RC4 code have confirmed that alleged RC4 is, in fact, the same algorithm.

RC4 is simple to describe and implement. Indeed, there is a three-line Perl implementation of it at <http://www.cypherspace.org/~adam/rsa/rc4.html>. The algorithm has an initialization, or key-scheduling, phase, in which the initial state of the pseudorandom byte generator is set up. In the second phase, the key stream is generated and exclusive-ORed into the plaintext to produce the ciphertext.

RC4's internal state consists of a 256-byte array, S, of unique 8-bit values, and two counters, i and j. The key-scheduling algorithm takes as input the sequence [image] Ki [image], which is the key concatenated with itself repeatedly to make a sequence of length 256 bytes, and performs the following three operations:

  1. m = 0

    For n = 0 . . . 255

    Sn = n

  2. For n = 0 . . . 255

    m = (m +Sn +Kn) mod 256

    swap Sn and Sm

  3. i = j = 0

Once the key-scheduling algorithm initializes the internal state, a random byte, R, is generated by:

i = (i +1) mod 256

j = ( j +Si) mod 256

k = (Si +Sj) mod 256

swap Si and Sj

R = Sk

These steps are iterated to produce a sequence of pseudorandom bytes [image] Ri [image]. Encryption proceeds by exclusive-ORing the ith byte of plaintext with the corresponding random byte. That is, Ci = Pi [image] Ri, where the [image] Pi [image] are the plaintext bytes and the [image] Ci [image] are the ciphertext bytes. Decryption works in exactly the same way. We show a python implementation of RC4 in Figure A.2.

Although RC4 is simple and may even seem ad hoc, it is an excellent algorithm with many desirable cryptographic properties. It is also very fast. RSA claims speeds of 1 MB/second even on a 33 MHz machine [Robshaw 1995], and the OpenSSL speed benchmark reports speeds on the order of 60 MB/second on a 1.6 GHz Pentium 4. In 2004, Marc Bevand achieved speeds of 319 MB/second on the AMD64 processor (<http://etud.epita.fr/~bevand_m/papers/rc4-amd64.html>). See [Mister and Tavares 1999] for an analysis of RC4's cryptographic properties. An important vulnerability in RC4's use with wired equivalent privacy (WEP) is discussed in [Fluhrer, Mantin, and Shamir 2001]. [Roos 1995] identifies a class of weak keys and recommends the first few bytes of RC4 output be discarded. A cautionary tale involving the misuse of RC4in this case, reusing the key streamcan be found in [Stevenson 1995].

Block Ciphers

As their name implies, block ciphers operate on fixed-sized blocks of data. The traditional size was usually 64 bits, but more recent block ciphers use block sizes of 128, 192, or even 256 bits. A block cipher takes an N-bit block of plaintext as input and outputs an N-bit block of ciphertext.

At first glance, it's difficult to see the difference between stream and block ciphers except for the larger unit of data operated on by block ciphers, and, indeed, each can take on the characteristics of the other. The salient difference is that whereas stream ciphers might encrypt two occurrences of the same character differently, depending on their position in the text stream, block ciphers will always encrypt the same block of bits the same way. In this sense, block ciphers are really just a "code book" that specifies an encrypted block for each plaintext block, and we could, in principle, implement them as a table lookup. As a practical matter, this isn't feasible, because such a code book would require two arrays of 2N entries of N bits each.

For the reasons discussed in the previous paragraph, block ciphers are said to operate in electronic code book (ECB) mode. This mode has some security problems because many messages have data in common, and it is sometimes possible to infer information about a message that has a block in common with another message. That is, if two messages have the same block of plaintext, they will have the same block of ciphertext.

To avoid these problems, we can add an extra step to the encryption process. We choose an arbitrary block, called an initialization vector (IV), and exclusive-OR it with the first plaintext block before we encrypt it. Before encrypting the second plaintext block, we exclusive-OR it with the first cipher block, and so on. That is, if EK is the block encryption algorithm with key K, we encrypt the message as:

CB0 = EK(PB0 [image] IV)

CBi = EK(PBi [image] CBi-1), i > 0

where IV is the initialization vector, [image] PBi [image] is the sequence of plaintext blocks, and [image] CBi [image] is the sequence of cipher blocks.

This is called cipher block chaining (CBC) mode. The IV need not be kept secret, although it often is, but it must be different for every message. Most experts recommend using a random value for the IV. Note that even if two plaintext blocks are the same, they will almost certainly encrypt to different blocks because they will be exclusive-ORed with different blocks first. The CBC mode process is illustrated in Figure 3.2. Decryption is similar, except that the IV and cipher blocks are exclusive-ORed after the decryption step.

Figure 3.2. Cipher Block Chaining

[View full size image]

Another effective way of using block ciphers is called counter (CTR) mode [Dworkin 2001]. With this mode, a counter is encrypted with the block cipher, the resulting n-bit block is exclusive-ORed into the plaintext block, and the counter is incremented. That is:

CBi = PBi [image] EK(CTRi)

where <PBi> is the sequence of plaintext blocks, <CBi> is the sequence of corresponding ciphertext blocks, CTRi is the ith counter value, and EK(X) represents encryption of X with the block cipher, using key K.

Notice that CTR mode effectively turns a block cipher into a stream cipher. As we'll see later, CTR mode can have certain advantages over CBC mode, but we must take care to ensure that the key stream is not reused. This means that we can never reuse a counter/key pair. It also means that we cannot allow the counter to wrap, or the key stream will be repeated. Typically, the counter is chosen to have a component that depends on the message, such as a message number, and another component that serves as the actual counter. Another suggested implementation merely takes a random IV as the counter and increments it after every encryption.

[Ferguson and Schneier 2003] regard counter mode as the preferred way of using block ciphers. Although they emphasize the dangers involved with its misuse, they believe that it leaks less information than any of the other modes (see Exercise 3.4). The advantages of CTR mode for block ciphers are also discussed in [Lipmaa, Rogaway, and Wagner 2000].

DES

The best-known and most-studied block cipher is, of course, the Data Encryption Standard (DES). It has been the worldwide standard for more than 25 years, but is now at the end of its life. The problem is not with the algorithm itselfthat's held up remarkably wellbut with its small key size of 56 bits, and to a lesser extent, the small, by modern standards, block size of 64 bits.

It is worthwhile to briefly examine the operation of DES because it illustrates many of the features of block ciphers. The complete specification is given in [NIST 1999], so we will content ourselves with covering the concepts without looking at every detail. [Schneier 1996] gives a fascinating history of DES, and discusses its design and cryptographic properties.

At first glance, the DES algorithm seems complex, especially in comparison to the simplicity of RC4. The basic idea, however, is quite simple. First, the 56-bit key is used to generate 16 48-bit round keys. Each round key is obtained from the original by shifting the original key by an amount that depends on the round and then extracting a 48-bit subset. After an initial permutation, an input block of 64 bits is split into two halves, L and R. The right half, R, is combined with one of the round keys by a function traditionally called f . The result is then exclusive-ORed into the left half, L, and L and R are swapped. This is repeated 16 times, after which the inverse of the original permutation is applied to the result. The traditional way of presenting this is shown in Figure 3.3, but it's easier to think of it as the recursion

Figure 3.3. DES Encryption Rounds

Equation 1

Equation 2

where Ki is the ith round key, and we have ignored the initial and final permutations. Ciphers that divide the input block into two halves and use a recursion such as this are called Feistel ciphers, or Feistel networks. Notice that from (1), we can obtain Ri-1 from Li and that if we exclusive-OR both sides of (2) with f (Ri-1, Ki), we recover Li-1 from Ri . This means that we can use the same algorithm for encryption and decryption by merely reversing the order of the round keys. That is, encryption uses the sequence K1, K2, . . . , K16, whereas decryption uses the sequence K16, K15, . . . , K1.

This fact also explains an apparent anomaly in Figure 3.3. Observe that in the last round, L16 and R16 are not swapped. Thus, an encrypted block can be fed back into the algorithm as is for decryption. This was an important consideration for DES because the original specification required that it be implemented in hardware, and the ability to decrypt by feeding the cipher text as is into the same algorithm meant that the same circuitry could be used for both encryption and decryption.

The ability to use the same algorithm for encryption and decryption is a characteristic of Feistel ciphers. As long as f (Ri-1, Ki) can be reproduced, it is always possible to invert the encryption using the same algorithm, even if f itself is not invertible.

Putting aside the internals of the f function for the moment, we see that each round of DES is reminiscent of RC4. The f function produces some pseudorandom data that is exclusive-ORed into the plaintext stream. There are obvious differences, of course. For one thing, the bits that get exclusive-ORed into Li depend on the plaintext as well as the key. This is an important point; one of the goals of the DES algorithm is to ensure that every bit of the encrypted block depends on every bit of the plaintext block and every bit of the key. Feeding the plaintext into f is a vital part of guaranteeing this.

The operation of the f function is illustrated in Figure 3.4. First, the expansion permutation rearranges the 32 bits of the R half-block and expands the result to 48 bits by repeating some of the bits. The expansion to 48 bits makes the result match the size of the round key, but more important, it means that half the bits in any Ri will affect multiple bits in the output of f.

Figure 3.4. The DES f Function

[View full size image]

Next, the round key is exclusive-ORed with the output of the expansion permutation, and the resulting 48 bits are split into eight groups of 6 bits. Each 6-bit group is fed into one of eight substitution boxes, or S-boxes. Each S-box maps its input into 4 output bits that are combined with the output of the other S-boxes to create a 32-bit result. These 32 bits are permuted by the P permutation to form the final output of f .

The S-boxes are the heart of the DES algorithm and are what gives it most of its strength. The structure of the S-boxes is simple; they merely perform a table lookup on the 6-bit input to obtain a 4-bit entry. The values used for those tables are anything but simple, however. They are carefully chosen to have certain cryptographic properties that make DES resistant to cryptanalytic attack.

The ever-expanding power of modern computers has rendered DES obsolete. As far back as the late 1970s, Diffie and Hellman speculated that a DES-cracking machine that could break DES by brute forcethat is, by trying every possible keycould be built for $20 million. They estimated that the machine would take a day to recover a key. And, indeed, in 1998 the Electronic Frontier Foundation built a DES-cracking machine, called Deep Crack, for less than $250,000. Deep Crack was able to recover the key for RSA's DES Challenge II in less than three days. The design of the machine and the story of its development are recounted in [Electronic Frontier Foundation 1998]. More recently, distributed networks of small general-purpose computers have been used in conjunction with Deep Crack to break DES in less than a day.

Triple DES

As we noted above, the major problem with DES is that the key has only 56 bits. That means that a brute-force attack takes at most 256 attempts, a number well within practical limits for today's machines. Triple DES (3DES) deals with this problem by encrypting the plaintext three times with three different keys. Although this yields an effective key size of only 112 bits, rather than the 168 we might expect, it does extend the life of DES for a few more years.

Triple DES is usually implemented in encrypt-decrypt-encrypt (EDE) mode, where the first key is used to encrypt a block, the second key is used to decrypt the result of step 1, and the third key is used to encrypt the result of step 2. If EKi is the encryption function for key Ki, and DKi is the decryption function for key Ki, we have

CB = EK3(DK2(EK1 (PB)))

PB = DK1(EK2(DK3 (CB)))

where PB is a plaintext block, and CB is the corresponding encrypted block. EDE mode does not have any cryptographic effect, but it does allow 3DES to be backward compatible with DES by setting K1 = K2 = K3. Note that when the three keys are the same, the result is the same as a single encryption or decryption with DES.

Despite partially solving the problem of the small key size of DES, 3DES still has problems. First, it is three times slower than DES, which is already slow when compared to most modern block ciphers. More important, 3DES still uses the 64-bit block size, which yields less security than the larger block size used in recent block ciphers. [Ferguson and Schneier 2003] recommend against using 3DES except for legacy applications that demand it.

AES

In 1997, the National Institute of Standards and Technology (NIST) solicited proposals for a new cipher to replace the aging DES. This new cipher was to be called the Advanced Encryption Standard (AES). NIST specified that AES must support a block size of at least 128 bits and key sizes of at least 128, 192, and 256 bits.

Fifteen candidates were submitted, and in August 1999, NIST announced the five finalists. The criteria for selection of the finalists and for AES itself included the security of the cipher, its performance, and its ease of implementation in hardware and software. On October 2, 2000, NIST revealed its selection of the Rijndael cipher for AES.

Rijndael (AES)

Rijndael supports block and key sizes of 128, 192, and 256 bits. There are 10 to 14 rounds, depending on the key size. The key-scheduling algorithm expands the initial key to N x (R + 1) bits, where N is the block size in bits, and R is the number of rounds. The first N bits are used as the key for round 1, the second N bits for round 2, and so on. The last N bits are used in a final key mixing after the last round.

Although both AES and DES use some of the same basic operations, such as S-boxes and permutations, AES is different from DES in several ways. First, AES is byte oriented: All the basic operations are performed on bytes rather than on bits as in DES. Second, AES is not a Feistel cipher. Indeed, decryption uses a different algorithm from encryption. Finally, the number of rounds is variable, depending on the key and block sizes.

Figure 3.5 shows a typical AES round for a block size of 128. The rounds for the other block sizes are similar. The input block is delivered to the round as 16 bytes labeled b0, . . . , b15. The output of the round is also 16 bytes, labeled c0, . . . , c15.

Figure 3.5. One Round of AES

[View full size image]

As the bytes enter at the top of Figure 3.5, they are exclusive-ORed with the 16 bytes of the round key K(i). The result is fed into 16 identical S-boxes that do a table lookup on the input byte to produce an output byte. Next, the outputs from the 16 S-boxes are permuted by the permutation

Equation 3

where the meaning of (3) is that b0 [image] b0, b1 [image] b5, b2 [image] b10, and so on. Notice that the bytes from each group of four are dispersed uniformly to each of the other three groups.

Finally, the output of the byte permutation is divided into groups of 4 bytes, and each group is subjected to a linear mixing function that produces 4 output bytes.

Technically, the linear mixing function is the linear transformation

over the finite Galois field GF(28), but as a practical matter, we can think of the linear mixing function as exclusive-ORing input bytes to produce an output byte.

The last round differs from the others in that the linear mixing function is skipped, and the output bytes from the permutation are exclusive-ORed with the final 128 bits of the expanded key.

The decryption rounds follow the same pattern except that the data flow is from bottom to top, the inverse of each of the operations is used, and the round keys are used in reverse order, as they were with DES.

The specification for Rijndael is given in [NIST 2002a]. NIST maintains an AES home page at <http://www.nist.gov/aes>, with pointers to the Rijndael home page, implementations, and information about the other AES candidates.

Blowfish

Blowfish is a block cipher developed by Bruce Schneier. Because the algorithm is fast and unencumbered, it's a popular encryption method that is used in several VPNs. Although its 64-bit block size is considered too small by modern standards, many of the applications that we are concerned with are still using Blowfish, so it is worth our while to take a quick look at it.

Blowfish uses a variable-length key of up to 448 bits, although 128 bits are more usual. The large key size adds considerable strength to the algorithm compared to DES, which Blowfish was designed to replace. Like DES, Blowfish is a Feistel cipher, and the Blowfish f function uses S-boxes, but the S-boxes depend on the key, which makes cryptanalysis of the algorithm more difficult. The key-scheduling algorithm generates 18 subkeys, P1, . . . , P18, and four S-boxes, S1, . . . , S4, from the key. Each S-box maps an 8-bit input to a 32-bit output.

Figure 3.6 shows the operation of the algorithm and also makes its structural similarity to DES clear. Each of the 16 rounds consists of simply exclusive-ORing its left input with one of the 18 subkeys, and its right input with the output of the f function. The f function is also simple. It uses only the S-boxes, exclusive-ORs, and 232 modular addition. This simplicity is what gives Blowfish its speed, especially on modern 32-bit processors. The operation of the f function is shown in Figure 3.7.

Figure 3.6. Blowfish Encryption Rounds

Figure 3.7. The Blowfish f Function

The Blowfish key-scheduling algorithm requires considerable computation. It is roughly equivalent to encrypting 4 kilobytes of data. The algorithm works by initializing the 18 subkeys and the 256 32-bit entries of each S-box to the hexadecimal digits of the fractional part of p. Next, the user's key is exclusive-ORed into the subkeys, cycling through the key repeatedly, if necessary, to fill out the 18 subkeys. Then, a block of 0s is encrypted, and the result replaces P1 and P2. The modified algorithm is now used to encrypt the results of the previous encryption, and the output replaces P3 and P4. This operation is performed 521 times until each of the subkeys and all the S-box entries are initialized.

Because of the time it takes to initialize the algorithm's state, Blowfish is not suitable for situations in which the key is changed frequently. Blowfish is ideal for applications such as VPNs, in which a key is used for some time before it is replaced.

Additional information about Blowfish is available on Schneier's Web site, <http://www.schneier.com/blowfish.html>, where he gives a complete discussion of the algorithm, an explanation of some of the design decisions, and pointers to several free implementations. As of this writing, there is no known practical attack against Blowfish. Certain weak keys can be detected, but not identified or exploited, in a reduced 14-round version of Blowfish, and a 4-round version is vulnerable to a differential analysis attack.


Section 3.3. Asymmetric Ciphers

3.3. Asymmetric Ciphers

One of the problems with symmetric ciphers is that they require both parties to the exchange of encrypted messages to have access to a shared secret: the key. If we think in terms of a typical application, encrypted email, we see immediately why this is a problem: We must give every possible correspondent a key to use when corresponding with us. Furthermore, this key must be different for each correspondent so that one can't read the messages of another. Because for n correspondents, each able to communicate privately with any other, this requires ½ (n2 - n) keys, the number of keys grows quadratically in the number of correspondents.

Sometimes, sharing a secret isn't possible. Consider the typical application of securing a Web transaction (see Chapter 6). Because an online merchant doesn't know a priori who its customers will be, it is not possible to use a shared secret to secure the transaction. There are many other situations in which it is impractical or impossible for both parties to use a preassigned key.

In this section, we consider algorithms that enable two parties to communicate securely without such problems. For reasons that will become clear shortly, this is usually called public key cryptography.

Asymmetric ciphers are those that have different keys for encryption and decryption. The idea goes back to [Diffie and Hellman 1976] and, independently, [Merkle 1978].

The GCHQ (Government Communications Headquartersthe British equivalent of the American National Security Agency) also has some claim to the idea of asymmetric ciphers, but its work was classified and unpublished until after the Diffie-Hellman and Merkle papers.

The notion was that keys would come in pairsone each for encryption and decryptionand that one key could not be derived from the other. These algorithms are important for public key cryptography, in which one key is public and used by anyone to encrypt a message that can be decrypted only by the holder of the other, secret, key. Because only the recipient has the secret key, the messages cannot be read by anyone else.

Asymmetric ciphers are based on one-way trapdoor functions, which are easy to compute but difficult to invert. It is the trapdoor function that makes it difficult to obtain one key from the other. See [Schneier 1996] for a discussion of many of these algorithms and the trapdoor functions on which they are based. Here, we consider only two of the asymmetric algorithms: RSA and ElGamal.

RSA

The RSA algorithm was invented by Ron Rivest, Adi Shamir, and Ken Adleman and described in their 1978 paper [Rivest, Shamir, and Adleman 1978]. RSA is based on the difficulty of factoring large numbers. Given two large prime numbers, p and q, the trapdoor function is to multiply p and q to obtain the product n. Obviously, this is trivial to compute, but the difficulty of factoring n into p and q makes it very hard to invert. The mathematics required to understand RSA is modestmostly some facts about modular arithmeticand, except for the proof that it works, is probably familiar to most of us. For an excellent review of the necessary mathematics, see [Ferguson and Schneier 2003]; a slightly more comprehensive review is given in [Menezes, Oorschot, and Vanstone 1996].

The description of RSA is simple. Pick two large random numbers, p and q, of about the same size. They should be at least 1,024 bits long, with larger numbers being more secure. Then choose a number e for the encryption key such that e has no factors in common with (p - 1)(q - 1). Popular choices for e are 3, 5, 17, and 65,537.

These values are chosen because they make it easier to perform the calculations discussed below. In practice, e is often chosen first, and p and q are chosen to ensure that (p - 1)(q - 1) has no factors in common with it.

Next, choose the decryption key d such that ed = 1 mod (p - 1)(q - 1). The condition on e and (p - 1)(q - 1) ensures that this is possible. We say that d is the multiplicative inverse of e mod (p - 1)(q - 1) and sometimes write d = 1/e mod (p - 1)(q - 1). The public key is the pair (n, e), and we can make it known to anyone who might wish to send us a message. The numbers p, q, and d are secret and should not be revealed. Only d is necessary to decrypt messages, so p and q could be discarded, but retaining them allows us to build more efficient implementations of the decryption algorithm.

Given a message m, thought of as a single large integer, such that m < n, we encrypt it as

Equation 4

where c is the encrypted message. We decrypt it as

Equation 5

We should take note of two things here. First, given that we choose p and q to be on the order of 1,024 bits, n [image] 2,048 bits long. Thus, we can't encrypt a message longer than about 256 characters. Second, making these calculations requires working with huge numbers, so in general, we will need to use an arbitrary-precision math library for the calculations.

It's not difficult to see why (4) and (5) work:

Equation 6

The only step that's not completely obvious is (6). This follows from Fermat's little theoremthe details are in [Menezes, Oorschot, and Vanstone 1996], but we don't need to understand any of that to use the algorithm.

A simple example will make these ideas clear. Let us choose two primes of 4 bits eachsay, 5 and 11for our p and q, and let's choose 3 for e. Next, we need to find a number d such that 3d = 1 mod (p-1)(q-1) = 1 mod 40. It is easy to check that 27 satisfies this condition.

In this case, the numbers are small enough that we can just search for d directly. In general, the easiest way to find d is to use the extended Euclidean Algorithm [Knuth 1998], but we needn't worry about this unless we are trying to implement the RSA algorithm. See Appendix A for bc and python scripts that calculate these inverses.

We now have everything we need to encrypt a message. The public key is (55, 3), and the secret key is 27. Let us encrypt the message 11012 (decimal 13):

c = 133 mod 55 = 2197 mod 55 = 52

To decrypt this, we use the secret key as in equation (5):

m = 5227 mod 55

Even with these small numbers, the calculations can get out of hand. Although we could calculate 5227 by hand (the result is 47 digits), it's easier to use an arbitrary-precision calculator, such as the UNIX utility bc for this:

$ bc -q
52^27%55
13

As expected, we get our original message, 13, back.

An algorithm that encrypts messages that are limited to 5 bits is not particularly useful, of course, but even with the more typical implementation, we are still limited to about 256 bytes. We could solve this problem by partitioning our messages into blocks of 5 bits and encrypting each block independently, as we do for block ciphers, but RSA is very slowthe typical software implementation of RSA runs at about 1 percent of the speed of DES [Schneier 1996]so RSA is almost never used this way.

Instead, we combine RSA with one of our symmetric ciphers. Recall that a problem with symmetric ciphers is that they require both parties to an exchange of encrypted messages to have access to the key. Public key systems, such as RSA, solve this problem as follows. Suppose that Alice wants to send an encrypted message to Bob.

The names Alice and Bob are traditionally used in cryptographic literature to refer to two people who wish to communicate with each other.

Alice picks a random number as a one-time session key for a symmetric cipherAES, sayand encrypts it, using Bob's public key. Alice then encrypts the message itself with AES, using the random session key, and sends both the RSA encrypted key and the AES encrypted message to Bob.

The actual process is a bit more complicated. An AES key, K, of 256 bits is too small to encrypt securely with RSA because for a public key of, say, (n, 3), where n has about 2,048 bits, we have Ke < n. Therefore, Ke mod n = Ke, and an attacker can recover K by merely taking the eth root. To avoid this, Alice can choose a large random number to encrypt with RSA. Both Alice and Bob then use this random number to generate the actual key, K. Another method is for Alice to pad K with random bits so that the total message has about the same number of bits as n. Other methods of encoding K and, more generally, any message m, are given in PKCS #1 [RSA Laboratories 2002]. The encoding methods in PKCS #1 add security because they use hash functions (Section 3.4) and pseudorandom masking functions that ensure that two similar or identical messages will have dissimilar encodings. At the same time, the encodings have a structure that the receiver can check to avoid certain chosen ciphertext attacks. See [Bleichenbacher, Kalisky, and Staddon 1998] and [Kaliski and Robshaw 1995] for details on how PKCS #1 encoding prevents many attacks on RSA-encoded messages.

When Bob receives these, he first uses his secret RSA key to recover the AES session key, and then uses that to decrypt the message. If several messages will be exchanged in a session, the same session key is used for each message, thereby avoiding the relatively slow RSA step for all messages but the first. We will see this same patternusing an asymmetric cipher to exchange session keys for a symmetric ciphermany times as we study VPNs and related security protocols.

ElGamal

If p is prime, and g, y [image] {1, 2, . . . , p - 1}, the discrete logarithm problem is to find an integer x such that y = gx mod p. In the real numbers, R, this is merely the normal logarithm, and x is easily determined, although it may not be an integer, of course. In the finite field Zp, which is what we are discussing, this is a problem on the same order of difficulty as factoring the prime p. Therefore, for large p, modular exponentiation is a suitable trapdoor function for an asymmetric cipher algorithm: It is trivial to perform modular exponentiation, but inverting it requires finding its discrete logarithm.

The ElGamal encryption algorithm [ElGamal 1985] is based on the difficulty of computing a discrete logarithm. We must use some care in picking p and g. Generally, we want p = 2q + 1, where q is also prime, and we want p to be on the order of 2,048 bits or more. [Ferguson and Schneier 2003] suggests the following method for picking g: Choose a random number a [image] {2, 3, . . . , p - 2}, and compute g = a2 mod p. If g = 1 or g = p - 1, pick another a and try again. Otherwise, g, which is called the group generator, is suitable.

Next, pick a random number x, and compute y = gx. The public key is the triple (y, g, p). The private key is x.

To encrypt a message m, choose a random number k that has no factors in common with p - 1, and compute the two numbers:

a = gk mod p

b = ykm mod p.

The encrypted message is the pair (a, b). To decrypt the message, compute

m = b/ax mod p

Note that

ax mod p =(gk )x mod p = gkx mod p = gxk mod p = (gx)k mod p = yk mod p

Thus, dividing b by ax (modulo p) yields the original message m.

To see how this works in practice, let q be 3 so that p = 7. Choose g = 2. Because 2 = 32 mod 7, g is a suitable choice for the generator. Let's use 4 for our secret key, so that y = 24 mod 7 = 2.

Suppose that we want to encrypt the message 1102 (decimal 6). First, we choose a random k with no factors of 2 or 3; let's say 5. We compute

a = 25 mod 7 = 4

b = 25 · 6 mod 7 = 3

To recover the message, we compute

ax mod 7 = 44 mod 7 = 4

b/ax mod 7 = 3 · 2 mod 7 = 6

where 1/ax = 2 mod 7.

Diffie-Hellman Key Exchange

ElGamal encryption is closely related to the Diffie-Hellman key-exchange algorithm [Diffie and Hellman 1976]. Diffie-Hellman enables two parties to dynamically agree on a shared secret over an insecure transmission medium without any previously shared information. Even if their entire session is captured, an attacker will not be able to discover the shared secret. This seemingly impossible task is in fact quite simple. The process is illustrated in Figure 3.8.

Figure 3.8. Diffie-Hellman Key Exchange

To produce the shared secret, Alice chooses a prime p and generator g, just as in ElGamal. Then Alice chooses a random private key xA, calculates [image] mod p, and sends the triple (p, g, yA) to Bob. Bob chooses his own random private key xB, calculates [image] mod p, and sends it to Alice. Note that it is impractical for an attacker to recover the two private keys xA and xB, because of the difficulty of the discrete logarithm problem.

Next, Alice generates her secret key, KA, as [image] mod p. Likewise, Bob calculates his own secret key as [image] mod p. But now we have

so Alice and Bob have, in fact, calculated the same key independently.

In many situations, Alice and Bob will have agreed on p and g in advance, so Alice need send only yA to Bob instead of the triple (p, g, yA). In some applications, such as IPsec, there are a small number of primes and generators that most implementations choose from, and Alice need send only an indication of which set she wishes to use, rather than the entire prime and generator.

ElGamal and Diffie-Hellman over Elliptic Curves

The ElGamal and Diffie-Hellman algorithms that we've discussed involve calculations over the finite field Zp, using the normal field operations, such as addition, multiplication, and exponentiation. It is possible to define an elliptic curve over Zp or GF(2n), and then implement the ElGamal and Diffie-Hellman algorithms as calculations on the points of the curve. The mathematics are considerably more demanding than what we have been using, so we will omit the details. A reasonably accessible introduction to elliptic curve cryptography and its application to Diffie-Hellman is in [Davis 2001].

The advantage of elliptic curve cryptography is that the discrete logarithm problem is considerably more difficult over an elliptic curve than it is in Zp, so smaller values of p can be used, with a consequent increase in speed and decrease in the amount of data that needs to be exchanged between peers during key negotiation. For example, Diffie-Hellman over Zp with a 1,024-bit prime has about the same security as Diffie-Hellman over an elliptic curve on the finite field GF(2n) with a prime of 185 bits [Doraswamy and Harkins 1999].


Section 3.4. Cryptographic Hash Functions, MACs, and HMACs

3.4. Cryptographic Hash Functions, MACs, and HMACs

One problem in implementing VPNs is message authentication. That is, how can we be sure that the message is from whom it says it is, and that it hasn't been tampered with in transmission? An everyday example of this is an email message signed with PGP, GPG, or a similar utility. The recipient of such a message can be sure that the sender is legitimate and that the message has not been altered by a third party.

In this section, we discuss some of the tools that provide these capabilities. We are not interested in utilities, such as GPG, but rather in the building blocks that are used to construct them. As we shall see, these tools have applications far beyond signing email messages.

One of the basic building blocks that we will need is a cryptographic hash function. These functions take an input of arbitrary length and produce a fixed-sized digest, or "fingerprint," of the input. A trivial example of a hash function on a message m is h(m) = m mod n for some n. Although such a hash function is useful for table-lookup applications, it is not a cryptographic hash function, because it lacks the essential properties required of a cryptographic hash function, h.

  • Given x, it is computationally infeasible to compute m such that x = h(m).

  • Given m1, it is computationally infeasible to compute m2 such that h(m1) = h(m2).

  • It is computationally infeasible to find m1 and m2 such that h(m1) = h(m2).

This last property is called strong collision resistance. It may seem superfluous, but hash functions lacking this property are vulnerable to various attacks based on the birthday paradox. See Section 18.1 of [Schneier 1996] for a description of one such attack.

The birthday paradox is the surprising result that if 23 people are in a room, the chances are better than even that 2 of them will have the same birthday.

An examination of the properties that hash functions should have and the place of strong collision resistance in those properties is presented in [Anderson 1993].

Although there are several cryptographic hash functions, we examine only two: MD5 and SHA. Both of these functions take a message of any length and produce a fixed-sized result: 128 bits for MD5 and 160 bits for the standard SHA algorithm, called SHA-1.

MD5

The MD5 algorithm was developed by Ron Rivest in 1992 and released to the public domain. Its specification and a reference implementation are given in RFC 1321 [Rivest 1992b]. Before describing the algorithm, let's see it in action. We use the FreeBSD md5 utility to compute the MD5 digest of the two strings 1 and 3:

$ md5 -s 1
MD5 ("1") = c4ca4238a0b923820dcc509a6f75849b
$ md5 -s 3
MD5 ("3") = eccbc87e4b5ce2fe28308fd9f2a7baf3

Two points are worth noticing here. First, even though the input strings are a single byte, they produce a 128-bit digest. Second, although the strings 1 and 3 vary in only a single bit, they produce two radically different digests. This is an example of the avalanche effect, where a change in one bit affects several bits in the result.

Given a message m of length lm, MD5 first pads the message with a 1-bit and then as many 0-bits as required to make lm = 448 mod 512. Then the least significant 64 bits of the message length are appended to make the padded message a multiple of 512 bits. Because the 1-bit is always appended, the message is always padded, even if it is already a multiple of 512 bits.

The MD5 algorithm operates on one 512-bit block at a time until the entire message is processed. During this process, MD5 maintains 16 bytes of state in four 32-bit registers (A, B, C,D). This state is modified by mixing it with data from the input block in a nonlinear way. After the last block has been processed, the 16 bytes of state are concatenated to form the digest. Before processing the first block, the state is initialized to (0x01234567, 0x89abcdef, 0xfedcda98, 0x76543210).

Figure 3.9 shows an overview of the MD5 process for one block of data. After the four rounds of mixing, the modified state (A', B', C',D') is added to the original input state (A, B, C,D) and used as the input state for the next block. The addition of the original state with the modified state is done one register at a time with 32-bit modular addition.

Figure 3.9. Process One Block with MD5

[View full size image]

The real work of MD5 is done by the four mixing rounds. The four rounds are similar but not identical. Each mixing round has a nonlinear function at its heart. These four functions, F, G, H, and I, are defined as

F(X, Y, Z) = (X [image] Y) [image] ((¬X) [image] Z)

G(X, Y, Z) = (X [image] Z) [image] (Y [image] (¬Z))

H(X, Y, Z) = X [image] Y [image] Z

I(X, Y, Z) = Y [image] (X [image] (¬Z))

where [image] is the bitwise AND operator, [image] is the bitwise OR operator, and ¬ is the bit complement operation.

F, G, H, and I are used to define the four round operations [image] , [image] , [image] , and [image]:

where <<< s represents a left rotation of s bits.

Let [image] where i is in radians. If we think of a single 512-bit block, B, of the message as comprising 16 32-bit words M0, M1, . . . , M15, round 1 of the nonlinear mixingreading left to right, top to bottomis

[View full size image]

The other three rounds, using [image] , [image] , and [image] , are similar:

[View full size image]

[View full size image]

SHA

The Secure Hash Algorithm (SHA) was designed by the National Security Agency (NSA) and standardized by NIST in 1995 as part of the Digital Signature Standard (DSS). The SHA specification is given in [NIST 2002b].

We are concerned mainly with the SHA-1 algorithm, which produces 160-bit digests. Also specified in [NIST 2002b] are SHA-256, SHA-384, and SHA-512, which produce digests of 256, 384, and 512 bits, respectively. As of this writing, these latter versions are still quite new and have not yet been subject to much review.

Because the SHA algorithms and MD5 are all based on ideas from the MD4 algorithm [Rivest 1992a], they share many of the same features, but the SHA algorithms are more secure, although slower.

SHA-1 uses five registers (A, B, C,D, E) to maintain a state of 20 bytes, which are initialized to (0x67452301, 0xefcdab89, 0x98badcfe, 0x10325476, 0xc3d2e1f0).

After padding the message m exactly as for MD5, each block is expanded from the 16 32-bits words M0, M1, . . . , M15 to 80 32-bit words by

This expansion ensures that every bit of the input block is mixed with the state multiple times.

During processing, the bits from each blockin the form of the [image] Wi [image] are mixed into the state in four 20-step rounds. Each round has a separate round constant, Kt:

and round function, ft(X, Y, Z):

With these definitions, we can describe the 80 steps of the four rounds as a simple loop.

For t = 0 . . . 79

T = (A [image] 5) + ft(B, C,D) + E + Wt + Kt

E = D

D = C

C = B [image] 30

B = A

A = T

After the final block is processed, the values in the five state registers are concatenated to form the digest.

Message Authentication Codes

A message authentication code (MAC) is a value used to verify that a message has not been tampered with since the MAC was computed. The normal protocol is for the recipient to be sent the MAC along with the message it is protecting. The receiver recomputes the MAC and verifies that it is the same value as that included with the message.

An obvious candidate for computing a MAC is one of our cryptographic hash functions. We can't simply use, say, the MD5 digest of the message as the MAC, because an attacker could alter the message and substitute the MD5 digest of the altered message for the original MAC. Nonetheless, we can use MD5 or one of the SHA algorithms as a building block for a MAC. The most straightforward method is to concatenate a secret key to the message and then take a digest of that. That is, if h is a cryptographic hash function, m is a message, and K a secret shared between two communicating peers, we might compute a MAC as MAC(m, K) = h(m||K), where the ||operator denotes concatenation. Notice that attackers can no longer substitute or alter the original message without detection, because they don't know K, and therefore can't compute a new MAC that will verify correctly.

Unfortunately, this MAC has some security problems [Preneel and Oorschot 1995], as does h(K||m) (Exercise 3.7). Even MAC(m, K) = h(K||m||K) is vulnerable [Preneel and Oorschot 1996], so we wouldn't expect to see them used to authenticate messages in any modern system.

Another possible MAC is based on using a block cipher in CBC mode. In this scheme, we first pad the message in a manner similar to that used for MD5 and then encrypt it with the block cipher in CBC mode, using K as the key. After the encryption, we discard all blocks but the last. For example, if m = B1||B2|| . . . ||Bn, where the [image] Bi [image] are the N-bit blocks used by the block cipher, and EK represents encryption with the chosen block cipher using key K, then we compute the MAC as

M0 = IV

Mi = EK(Bi [image] Mi-1)

MAC(m, K) = Mn

Traditionally, IV is set to 0, but any of the normal IV schemes can be used.

HMAC

A simpler scheme that uses one of the cryptographic hash functions as a building block is HMAC. The HMAC specification and a reference implementation using MD5 are given in RFC 2104 [Krawczyk, Bellare, and Canetti 1997]. Let B be the length in bytes of the block size used by the cryptographic hash function, h. For MD5 and SHA-1, B = 64. Then let L be the length in bytes of the output of the hash function. L is 16 for MD5 and 20 for SHA-1. The key, K, should be at least L bytes long and no longer than B bytes. If K is longer than B bytes, it can be reduced to L bytes by hashing it with h. In any event, K is expanded to B bytes by appending 0s. Given a message m, we compute HMAC as

HMAC(m, K) = h((K [image] opad) || h((K [image] ipad) || m))

where ipad is B bytes of 0x36, and opad is B bytes of 0x5c.

HMAC is believed to have good security and is simple to implement, so it is widely used. The authors of RFC 2104 provide an analysis of HMAC and the rationale for its design in [Bellare, Canetti, and Krawczyk 1996]. We will see HMAC used in SSL (Chapter 6) and IPsec (Chapter 9).


Section 3.5. Digital Signatures

3.5. Digital Signatures

Suppose that Alice sends a message to Bob. Digital signatures provide a way for Alice to certify that she is the sender of the message and that the message has not been altered after it was signed. As the name suggests, a digital signature is the digital equivalent of the traditional written signature.

This concept is similar to the notion of the message authentication code that we discussed in the previous section, but as we shall see, MACs are not appropriate for use in digital signature applications. The major problem is that MACs are symmetric algorithmsthey use the same key to verify the MAC as they do to generate the MAC.

It's easy to see why this is a problem: If Bob has Alice's signature key, he can forge messages from Alice. Furthermore, Bob can't demonstrate the genuineness of the message to third parties, because he can't prove that Alice, not he, signed the message. This last propertybeing able to prove to a third party that Alice signed the messageis called nonrepudiation and is an important concern because one use of digital signatures is for Alice to sign, say, a contract in digital form. There is also the problem of scaling that we discussed in connection with symmetric ciphers: The number of keys required grows quadratically with the number of parties wishing to send signed messages to each other.

These considerations suggest using one of our asymmetric algorithms to form a digital signature. Fortunately, this is easy to do, and we shall discuss two of the most-used methods: RSA and DSS.

RSA Digital Signatures

It's natural to use RSA as a way of signing messages. When using RSA to encrypt messages, Alice encrypts the message with Bob's public key and sends the message to Bob, who uses his private key to decrypt it. There is, however, nothing special about the role of the two keys; Alice could just as well encrypt the message with her private key. That would mean that anyone with Alice's public key could decrypt the message, so doing this serves no privacy function, but observe that anyone who does decrypt it with Alice's public key will know that the message is from Alice and that it hasn't been altered, because only Alice could have encrypted it. Alice has, in effect, signed the message. This method was suggested by Rivest, Shamir, and Adleman in their paper describing the RSA algorithm. In fact, that paper, [Rivest, Shamir, and Adleman 1978], was entitled A Method for Obtaining Digital Signatures and Public-Key Cryptosystems, suggesting that they viewed the ability to use the algorithm for digital signatures as important as its use for encryption. The paper discusses using RSA for digital signatures in detail.

Just as with encryption, it usually doesn't make sense to sign a message by encrypting the message itself. Rather, the normal procedure is to first take a digest of the message, using a cryptographic hash function, and then sign the digest by encrypting it with a private key. Just as with encrypting session keys, one must encode the signature in some way to avoid obvious weaknesses, such as small digests. PKCS #1 [RSA Laboratories 2002] specifies two such methods; [Ferguson and Schneier 2003] suggests another.

To avoid certain attacks, there are usually separate keys for encryption and signing. Typically, the same modulus (n = pq) is used, but a different e, and therefore d, is chosen for signing and encryption. This is, however, an implementation detail and doesn't affect the way we use and form digital signatures.

When Bob receives a message from Alice, he verifies the signature by decrypting the digest with Alice's public key, computing the hash of the message himself, and verifying that the two values are the same. Recall that given a message, m, it is very difficult to find another message m' such that they hash to the same value. For this reason, signing the hash of a message provides the necessary verifiability.

The Digital Signature Standard

On May 19, 1994, NIST published the Digital Signature Standard (DSS) as FIPS (Federal Information Processing Standards) 186. The standard was revised in 1998 (FIPS 186-1) and again in 2000 (FIPS 186-2). The latest version, [NIST 2001], contains an important change notice dated October 5, 2001.

DSS specifies an algorithm, the Digital Signature Algorithm (DSA), that is used to digitally sign messages. Although DSA is similar to ElGamal encryption, it is intended solely for signing digital documents.

However, [Schneier 1996] points out that one can, in fact, use it for encryption.

FIPS 186-2 also allows digital signature algorithms using RSA and elliptic curves, but the standard does not describe these algorithms. It merely includes them by reference to their specifications (ANSI X9.31 and X9.62).

To use DSA, we first pick

  1. A prime modulus p such that 21023 < p < 21024

  2. A prime q such that q divides p - 1, and 2159 < q < 2160

  3. A number h such that 1 < h < p - 1 and h(p-1)/q mod p > 1

  4. A random number x such that 0 < x < q

Next, we calculate g = h(p-1)/q and y = gx. The numbers p, q, and g are public and can be shared by a group of users. The public key is y, and the corresponding private key is x.

To sign a message m, we pick a random number k such that 1 < k < q, and calculate

r = (gk mod p) mod q

s = (k-1(S(m) + xr)) mod q

where k-1 is the multiplicative inverse of k mod q, and S(m) is the SHA-1 hash of m. A new value of k is chosen for every signature. The digital signature of m is the two numbers r and s.

To verify the signature, we first check that 0 < r, s < q and reject the signature if not. Then we calculate

w = s-1 mod q

u1 = (wS(m)) mod q

u2 = (rw) mod q

v = ((gu1yu2) mod p) mod q

We consider the signature verified if v = r. A proof that v = r for the same message m is in [NIST 2001].

MD5 and SHA-1 Security

One of the necessary properties of a cryptographic hash function is strong collision resistance. That is, given a hash function h, it is computationally infeasible to find messages m1 and m2 such that h(m1) = h(m2).

By the birthday paradox, computationally infeasible means that it takes O(2½) operations to find a collision, where l is the length in bits of the hash function output. We often express this by saying that finding a hash collision by brute force takes 2½ work. Thus, for example, the expected work to find a SHA-1 collision is 280.

At the CRYPTO 2004 conference in August 2004, a team of Chinese cryptographers led by Xiaoyun Wang announced that it had devised a method to generate collisions in MD5and other related hash functions but not SHA-1thus violating the strong collision resistance property. Wang's announcement did not include any details, but she and her colleagues did publish a short note [Wang, Feng, Lai, and Yu 2004] that showed colliding messages and stated that finding them took about an hour on an IBM P690 supercomputer. A later paper [Wang and Yu 2005] provided the details of the Wang team's method, which uses a form of differential cryptanalysis to find the collisions.

In early 2005, Vlastimil Klima discovered an independent method that was able to generate MD5 collisions on a 1.6 GHz laptop computer in about 8 hours [Klima 2005].

[Lenstra, Wang, and Wegner 2005] showed how to use Wang's method to produce a pair of X.509 certificates (Section 3.6) with the same MD5-based signature. The two certificates differ only in their public keys and thus don't constitute a usable exploit, but they do suggest that using MD5 as a signature method is no longer safe.

In February 2005, [Wang, Yin, and Yu 2005] announced an attack on SHA-1 that can find collisions with 269 work instead of the 280 work required for brute force. At the time of this writing, the details of the attack have not been published.

Although O(269) operations is still on the far side of practical, it is just barely so. Thus, even though the practical effects of the attack are limited, it does sound the death knell for SHA-1. We can expect that a combination of refinements in the attack and ever-expanding computing power will eventually force the abandonment of SHA-1. Indeed, NIST has already announced its intention to phase out SHA-1 in favor of stronger hash functions in the SHA family, such as SHA-256 and SHA-512, by 2010 (<http://csrc.nist.gov/hash_standards_comments.pdf>).

It is important to keep these results in perspective. They don't mean that digital signatures, secure email, and other applications of hash functions are suddenly unsafe. Indeed, some hash-based functions, such as HMAC, are not affected at all. Most important, we should be aware of what these attacks cannot do: they cannot find a preimage. That is, given a hash function, h, and a hash value, x, it is still computationally infeasible to find a message, m, such that h(x) = m.


Section 3.6. Certificates

3.6. Certificates

One problem with using public key cryptography that we've ignored so far is how to distribute the public keys. When Alice wants to send a message to Bob, she must first find Bob's public key. Likewise, if Alice signs the message and Bob wants to verify it, he must find Alice's public key. This problem was recognized from the beginning of public key cryptography and was usually glossed over by saying that Alice and Bob would put their public keys, along with their names and perhaps some other identifying information, in a "public database" available to anyone who needed to locate another person's public key [Diffie and Hellman 1976, Rivest, Shamir, and Adleman 1978].

Certificates are often used as a solution to the problem. Most of us are familiar with certificates from their use in secure Web browsing (we discuss this in detail in Chapter 6). The basic idea is that the certificate binds an identitya person's name, sayto their public key. The certificate is signed, as described in the previous section, by a trusted organization called a certificate authority (CA). This still leaves open the method of distributing the certificates, but notice that we have gained something: If Bob sends Alice his certificate so that she can communicate with him, Alice is better off than if Bob had merely sent his public key, because the certificate is signed and Alice can be sure, to the extent that she trusts the CA, that it is, in fact, Bob's certificate and not that of someone who is impersonating Bob.

A system such as this, where a CA signs certificates that bind users' identities to public keys, is called a public key infrastructure (PKI). The ideal PKI is a universal one in which a central authoritythe government or even a worldwide organization, such as the UN, sayissues a certificate for anyone who needs one. The problem with this, aside from the obvious administrative problems, which are probably intractable on their own, is trust. We noted above that when Bob sends Alice his certificate, Alice can be sure of Bob's identity only to the extent that she trusts the CA. As noted in [Ferguson and Schneier 2003], no organization is trusted by most people, let alone everyone, so the ideal of the universal PKI is doomed from the start.

There are other problems with the PKI notion as well, especially those PKIs that attempt to provide a general solution rather than focus on a particular small problem. Fortunately, our interest in certificates is restricted to their use in VPNs, and that is a small enough problem that solutions are possible. Chapters 19 and 20 of [Ferguson and Schneier 2003] provide an excellent discussion of PKIs, the problems they must overcome, and examples of their use in solving smaller specific key-distribution problems. See [Wilson 2003] for more thoughts on using PKI for small, focused applications.

Like cryptography itself, the subjects of PKI and certificates embody far too much for us to cover in detail. Indeed, whole books have been written about PKI. We look briefly at the most common type of certificate in the next subsection.

X.509 Certificates

The most common type of certificate is the X.509 certificate, so called for the International Telecommunication Union (ITU) standard that defines it [International Telecommunication Union 2000]. Most observers consider the X.509 specification a poster child for all that can go wrong with standards committees. The standard is at once bloated and incomplete. As Peter Gutmann [Gutmann 2000] says, "Since the original X.509 spec is somewhat vague and open-ended, every non-trivial group which has any reason to work with certificates has to produce an X.509 profile which nails down many features which are left undefined in X.509." These profiles are largely incompatible, so we end up with many different types of certificates that can't interoperate.

The Internet PKI profile is the responsibility of the IETF PKIX working group <http://www.ietf.org/html.charters/pkix-charter.html>. The profile itself is published as RFC 3280 [Housley, Polk et al. 2002], but there are several supporting documents. As of this writing, the PKIX home page lists several Internet Drafts as well as 17 RFCs in addition to RFC 3280more than 2,000 pages.

Figure 3.10 shows the structure of an X.509 certificate. The Version section specifies which of the three versions of the X.509 specification applies to this certificate. Each certificate that a CA issues has a unique serial number that appears in the Serial Number section. The Signature Algorithm specifies which digital signature algorithm the CA (the Issuer) used to sign the certificate. For security reasons, certificates are valid for a limited time. The Validity section lists the start and end dates of the certificate's validity. The Subject and Subject Public Key Information sections contain the name of the holder of the certificate and the associated public key. The Extensions section contains additional information required by individual profiles. Finally, the Signature section contains the CA's digital signature.

Figure 3.10. X.509 Certificate Structure

[View full size image]

Here is a printout of the information from one of the certificates that we will use in Chapter 6:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 9 (0x9)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, ST=Florida, L=Tampa, O=Text CA,
            CN=bsd.jcs.local
        Validity
            Not Before: Mar 31 20:02:42 2003 GMT
            Not After : Mar 30 20:02:42 2004 GMT
        Subject: C=US, ST=Florida, L=Tampa, O=sslecho,
            CN=linux.jcs.local
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:d6:6f:d6:40:00:8a:c6:86:00:b8:31:62:f3:a6:
                    bd:c1:f0:10:b5:69:34:8c:f7:d6:09:98:66:9d:dd:
                    a5:90:5e:58:fb:06:9d:59:21:75:fb:ac:ab:86:56:
                    83:57:af:85:1e:53:90:45:f7:e9:3f:66:b1:f3:e7:
                    fd:59:c1:88:ee:86:13:3c:79:55:c9:50:58:ae:5a:
                    32:d5:6e:aa:a7:f0:fd:2c:88:b9:89:1c:9d:3e:95:
                    27:6b:cc:a9:1f:5e:c0:99:d5:65:79:1e:2d:64:d3:
                    63:dd:99:8f:1f:22:1d:2f:2e:1b:f9:39:6c:c5:1e:
                    b3:01:a0:1a:07:56:21:5b:c3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Netscape Cert Type:
                SSL Server
     Signature Algorithm: sha1WithRSAEncryption
         4b:e7:22:94:f9:a9:c3:db:6b:a5:c3:ea:39:b7:9a:04:36:c9:
         de:d7:c2:ed:59:d7:bb:b9:4c:ec:35:a4:15:e9:32:d6:b0:ea:
         d8:64:5d:5c:41:3f:bb:c9:41:c7:32:fd:ad:47:52:20:c4:d5:
         04:3a:92:a8:59:f8:34:3c:57:bd:cc:15:ac:f4:3e:59:11:3f:
         c4:3f:2f:a5:7f:ef:89:8f:13:51:e6:9c:a7:94:20:71:ed:5a:
         1d:57:65:bb:38:34:2f:0a:86:73:e2:18:e0:8f:23:4d:d0:a3:
         37:b6:ee:0f:44:07:1d:94:66:70:78:ef:31:d1:97:50:11:ec:
         25:c3

We use several certificates such as this in Chapter 6, where we examine SSL. As is typical for a private organization, we have set up our own CA (Text CA) to sign these certificates. We see this in the Issuer section of the printout.

Certificate Chains

If we imagine a large international corporation that wants to issue certificates to its employees for email or remote access, say, we see that the corporation is faced with an administrative problem. How are all the business units and branch offices going to get their certificates signed? They could send them to the home office, where they would be signed by the company's CA, but this would take time and introduce verification problems because the home office won't know the employees personally. It would be much better to have the local offices sign the certificates for the employees who work there, but that would require giving each branch a copy of the CA's private key, a significant security risk.

To solve this problem, it is possible for the CA, now called the root CA, to create sub-CAs that are authorized to sign user certificates. To do this, the root CA issues special certificates to the sub-CAs and signs them. The sub-CAs, in turn, use these certificates to sign user certificates. This hierarchy can be extended to several levels. For example, the root CA might sign certificates for each business unit's CA, which might, in turn, sign certificates for each branch's CA, and so on. Note that a user who wants to verify another user's certificate doesn't need to know and trust each sub-CA, because the sub-CA has been vouched for by its immediate parent and ultimately by the root CA via the signing of the sub-CAs' certificates.

Revocation

By far the most difficult problem to solve in setting up a PKI is providing some means of revoking certificates. Revocation is necessary because employees leave a company, private keys are compromised, or some other event renders the certificate invalid.

As is the case of the certificates themselves, the revocation problem is much easier if we restrict our attention to a small, specific PKI implementation rather than try to create a general solution. A common example is a secure Web server's SSL certificate. If the certificate becomes invalid for some reason, the system administrator need merely replace it, because, as we'll see in Chapter 6, the SSL server sends the client a copy of the certificate when the SSL session is established [Gutmann 2003a]. Similarly, certificates used to allow remote logins are effectively revoked by merely closing the account to which they are tied. As we noted earlier, [Ferguson and Schneier 2003] has an excellent summary of the various revocation schemes. See [Zheng 2003] for a detailed analysis of several revocation schemes and some of the engineering tradeoffs involved in choosing one.


Section 3.7. Summary

3.7. Summary

In this chapter, we looked at some basic cryptography that we will need in the rest of the text. In our examination of stream ciphers, we studied RC4a simple but very effective cipher that generates a pseudorandom key stream that is exclusive-ORed into the plaintext to encrypt it.

In our study of block ciphers, we looked at DES and Rijndael in detail and mentioned the 3DES and Blowfish ciphers. We saw how running ciphers in CBC mode can improve their security by obscuring data that occurs in more than one message.

One problem with stream and block ciphers is that the parties to the communication must share a secret key in advance. This problem can be avoided by using an asymmetric cipher, such as RSA or ElGamal. Because asymmetric ciphers have different keys for encryption and decryption, each party can publish its public (encryption) key so that anyone can use it to encrypt a message for them. Because a message can be decrypted only with the secret key, the communication is secure. We saw how the same ideas can be used by two parties to independently calculate a secret key without any previously shared information.

Next, we studied cryptographic hash functions and their use in message authentication codes. These ideas can be generalized to produce a digital signature that guarantees authenticity of a document and provides for nonrepudiation.

Finally, we took a brief look at certificates and public key infrastructures. A general PKI is very difficult to produce but can be effective for smaller, specific applications.


Exercises

3.1

How many possible internal states does the RC4 algorithm have? Hint: The state array represents a permutation of 256 values, and each of the indices i and j can have any value between 0 and 255.

3.2

Implement RC4 in your favorite language.

3.3

Draw a diagram similar to Figure 3.2 showing the CBC decryption process.

3.4

Suppose that we are using a block cipher in CBC mode to encrypt plaintext blocks <Pi> into ciphertext blocks <Ci>, and that Cj = Ck for some j [image] k. Show that this implies that

Pj [image] Pk = Cj-1 [image] Ck-1

What are the implications of this if the <Pi> are highly redundant text, such as English text? If we are using CTR mode instead of CBC mode and Cj = Ck, what can we say about Pj and Pk?

3.5

In Section 3.4, we saw how a block cipher can be used to generate a message authentication code. How could we use a block cipher to build a cryptographically strong pseudorandom number generator?

3.6

In Section 3.3, we observed that Alice can't use RSA to directly encrypt a 256-bit block cipher key, K, because Ke < n and so Ke mod n = Ke and an attacker could merely extract the eth root to recover K. One solution to this was for Alice to choose a large random number that she and Bob would use to generate a key K and to encrypt this random number instead of K with RSA. How could Alice and Bob generate a 256-bit key from a large random number?

3.7

Review the MD5 and SHA-1 algorithms and notice that after processing each 512-bit block of the message, the entire state of the computations so far is contained in the four (MD5) or five (SHA-1) register variables. Given m and h(K || m), show how it is possible to compute h(K || m || y), where y is arbitrary text. This is known as an extension attack. Give an example to show how this attack might be used.


Chapter 4. Tunnels

    Section 4.1. Introduction

    Section 4.2. IP-in-IP Tunnels

    Section 4.3. PPPoE

    Section 4.4. GRE

    Section 4.5. PPTP

    Section 4.6. L2TP

    Section 4.7. MPLS

    Section 4.8. gtunnel

    Section 4.9. Summary

    Exercises


Section 4.1. Introduction

4.1. Introduction

In this chapter, we introduce the notion of tunnels and tunneling. Tunneling is a way of forming a virtual network on top of a physical network. That's a bit murky for a definition, but let's agree to accept it provisionally until we look at an example.

Suppose that we have two Novell Netware local area networks (LANs) in separate locations that we would like to connect through the Internet. Novell networks use IPX packets for their network-layer encapsulation and thus cannot route packets on an IP network directly.

IPX provides a connectionless unreliable datagram service similar to that provided by IP in TCP/IP.

There are several ways of linking the two LANs; one way, suggested in RFC 1234 [Provan 1991], is shown in Figure 4.1.

Figure 4.1. Tunneling IPX Packets Through the Internet

[View full size image]

The IP gateway attached to Novell network 1 listens for IPX packets on the LAN, encapsulates them in UDP datagrams, and sends them over the Internet to the IP gateway attached to Novell network 2. When a UDP datagram arrives at the second gateway, the gateway removes the IPX packet from the UDP datagram and injects it into the second Novell LAN.

We say that we have tunneled IPX through the IP network. In terms of our provisional definition, we have overlaid a virtual IPX network onto an IP network. A slightly different viewpoint is that our tunnel simulates a direct wire between the two LANs. An essential aspect of both views is that the traffic in the tunnel does not interact with the rest of the IP network; a packet enters one end of the tunnel and can leave only through the other end. While in the tunnel, the IPX packet plays no role in its routing or delivery. To the Internet infrastructure, the IPX packets are merely opaque data.

Note that our tunnel provided no security: The data in the tunnel was neither encrypted nor authenticated. This lack of security would not be acceptable in most practical situations; enterprises want their data to be safe from prying eyes and protected from alteration. In this chapter, we focus on tunneling technology and defer discussion of the security aspects until we consider virtual private networks in Part 2.

As we mentioned in Chapter 2, the fundamental notion in tunneling is encapsulation, where each layer in a protocol stack encapsulates the data from higher layers by adding a header and perhaps a trailer to that data. Thus, we have a TCP segment encapsulated in an IP datagram, which is in turn encapsulated in an Ethernet frame.

In Chapter 2, all our examples of encapsulation involved a lower layer encapsulating the data of a higher layer. Our Novell example turns this on its head: The network-layer IPX packet is encapsulated in the transport-layer UDP datagram. A lower-layer protocol is encapsulated in a higher-layer protocol.

This leads us to a better definition for a tunnel: Tunneling is the act of encapsulating the data from one protocol in the data of a protocol at the same or higher layer. The encapsulating protocol is said to be a tunnel for the lower-layer protocol. Although the Novell example does not make it clear, the lower-layer protocol can encapsulate higher-layer protocols as usual. Figure 4.2 shows a typical example.

Figure 4.2. PPP Frames Tunneled in UDP

[View full size image]

In this case, UDP is encapsulating a PPP frame that is carrying a TCP segment: We are tunneling PPP in UDP. Tunnels like this are easy to build, as we shall see later. For now, let's look at a tunnel like this in operation.

We build the tunnel between laptop and bsd, as shown in Figure 4.3.

Figure 4.3. A PPP in UDP Tunnel

The endpoints of the PPP connection are 192.168.0.1 at bsd and 192.168.0.2 at laptop. We label this a virtual PPP connection because the data actually flows through the tunnel on the 172.30.0.0/24 segment, as shown by the shaded path, rather than directly between the two PPP interfaces.

After bringing the tunnel up, we ping 192.168.0.1 from laptop and capture the traffic with tcpdump. Here is the output for a single ping:

1   12:22:09.215457 laptop.1050 > bsd.7050: udp 88
1.1    4500 0074 0565 0000 4011 1ccb ac1e 000c    E..t.e..@.......
1.2    ac1e 0001 041a 1b8a 0060 881b ff03 0021    .........'.....!
1.3    4500 0054 0564 0000 4001 f3f1 c0a8 0002    E..T.d..@.......
1.4    c0a8 0001 0800 9ddf 4501 0000 b194 473f    ........E.....G?
1.5    2e48 0300 0809 0a0b 0c0d 0e0f 1011 1213    .H..............
1.6    1415 1617 1819 1a1b 1c1d 1e1f 2021 2223    .............!"#
1.7    2425 2627 2829 2a2b 2c2d 2e2f 3031 3233    $%&'()*+,-./0123
1.8    3435 3637                                  4567

The encapsulating UDP datagram is shown in boldface in lines 1.1 and 1.2. Notice that the source address is the 172.30.0.12 (0xac1e000c) interface of laptop, and that the destination address is the 172.30.0.1 (0xac1e0001) interface of bsd.

On line 1.2, we see the PPP header:

1.2    ac1e 0001 041a 1b8a 0060 881b ff03 0021     .........'.....!

There is no flag byte, because the FreeBSD PPP operates in synchronous mode when using UDP to carry PPP frames. In synchronous mode, PPP expects the synchronous digital line to provide the flag. For the same reason, there is no PPP trailer: The synchronous line provides the CRC.

Finally, in lines 1.31.8, we see the original IP datagram that carries the ICMP echo request:

1.3     4500 0054 0564 0000 4001 f3f1 c0a8 0002     E..T.d..@.......
1.4     c0a8 0001 0800 9ddf 4501 0000 b194 473f     ........E.....G?
1.5     2e48 0300 0809 0a0b 0c0d 0e0f 1011 1213     .H..............
1.6     1415 1617 1819 1a1b 1c1d 1e1f 2021 2223     .............!"#
1.7     2425 2627 2829 2a2b 2c2d 2e2f 3031 3233     $%&'()*+,-./0123
1.8     3435 3637                                   4567

Notice that the source address is 192.168.0.2 (0xc0a80002), the laptop end of the PPP connection. Similarly, the destination address is 192.168.0.1 (0xc0a80001), the bsd end of the PPP connection.

The tunnel in Figure 4.2 might seem contrived, but it is, in fact, quite typical. We shall see several examples of tunnels like it shortly. For now, notice that it is different from the tunnel in Figure 4.1. The tunnel used to link the two Novell LANs tunneled a network-layer protocol in a transport-layer protocol. The tunnel of Figure 4.2 tunneled an interface-layer protocol in a transport-layer protocol. This variety is typical. We shall see examples of an interface protocol tunneled in another interface protocol, of an interface protocol tunneled in a network-layer protocol, and of an interface protocol tunneled in a transport-layer protocol. Similarly, we will see examples of network- and transport-layer protocols tunneled in the protocols of equal or higher layers.


Section 4.2. IP-in-IP Tunnels

4.2. IP-in-IP Tunnels

Let's begin our case study of tunnels with an almost trivial example. In this tunnel, IP datagrams are encapsulated in IP datagrams, as shown in Figure 4.4.

Figure 4.4. IP-in-IP Encapsulation

[View full size image]

The outer IP header will have a protocol field of 4 (Figure 2.12), indicating that its payload is another IP datagram. The inner IP header will have a protocol field indicating the protocol that it is carrying.

We can see an example of this by using the FreeBSD generic tunnel (gif) interface to build an IP-in-IP tunnel from laptop to bsd. On laptop, we configure the tunnel by first creating the gif interface and then configuring it with logical and physical addresses for both ends:

laptop# ifconfig gif0 create
laptop# ifconfig gif0 192.168.0.2 192.168.0.1  logical addresses
laptop# gifconfig gif0 172.30.0.12 172.30.0.1  physical addresses

We verify the configuration of the tunnel by running ifconfig on laptop:

laptop# ifconfig gif0
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
    tunnel inet 172.30.0.12 --> 172.30.0.1
    inet 192.168.0.2 --> 192.168.0.1 netmask 0xffffff00
    inet6 fe80::a00:46ff:fe63:d630%gif0 prefixlen 64 scopeid 0x8

The output shows that the logical address endpoints of the tunnel are 192.168.0.2 on the laptop side and 192.168.0.1 on the bsd side. The network, or physical, addresses of the endpoints are 172.30.0.12 and 172.30.0.1, the addresses of the physical interfaces on laptop and bsd. We do a corresponding configuration on bsd.

When we capture a ping sent through this tunnel, we get

1   16:45:08.819974 laptop > bsd: 192.168.0.2 > 192.168.0.1:
     icmp: echo request (ipip-proto-4)
1.1    4500 0068 0f3d 0000 1e04 350c ac1e 000c    E..h.=....5.....
1.2    ac1e 0001 4500 0054 0f3c 0000 4001 ea19    ....E..T.<..@...
1.3    c0a8 0002 c0a8 0001 0800 ec67 7101 0000    ...........gq...
1.4    54d2 473f 0782 0c00 0809 0a0b 0c0d 0e0f    T.G?............
1.5    1011 1213 1415 1617 1819 1a1b 1c1d 1e1f    ................
1.6    2021 2223 2425 2627 2829 2a2b 2c2d 2e2f    .!"#$%&'()*+,-./
1.7    3031 3233 3435 3637                        01234567

The outer IP header is in boldface in lines 1.1 and 1.2. As we see from the tenth byte of the header, the protocol field is set to 4, IP-in-IP (Figure 2.12). The source address is 172.30.0.12 (0xac1e000c)the physical address of bsdas expected. Similarly, the destination address is the physical address of bsd, 172.30.0.1 (0xac1e0001).

The inner IP header is on lines 1.2 and 1.3:

1.2    ac1e 0001 4500 0054 0f3c 0000 4001 ea19    ....E..T.<..@...
1.3    c0a8 0002 c0a8 0001 0800 ec67 7101 0000    ...........gq...

This time, the protocol field is set to 1 (ICMP), and the source and destination addresses are 192.168.0.2 (0xc0a80002) and 192.168.0.1 (0xc0a80001).

The utility of IP-in-IP tunnels may not be clear, so let's consider a common example. Suppose that we have two geographically separated networks with RFC 1918 (private) addresses and want to make the two networks appear as a single large network. For specificity, let's assume that the hosts in the first network have addresses in the 10.0.1.110.0.1.126 range and that the hosts in the second network have addresses in the 10.0.1.12910.0.1.254 range. When we say that the two networks should appear as a single large network, we mean that the host at 10.0.1.1 should be able to send a datagram directly to 10.0.1.129. That is, the IP datagram will have a source address of 10.0.1.1 and a destination address of 10.0.1.129.

Note that we can't solve this problem with NAT, because the destination address is nonroutable. NAT can still adjust the source address, of course, but it can't compensate for the nonroutable destination address.

We show a solution to this problem in Figure 4.5, where the two networks are connected by an IP-in-IP tunnel. The two gateway routers in the figure (GW1 and GW2) are called the tunnel endpoints. As shown in the figure, the physical addresses of the tunnel are 96.29.5.1 and 96.29.5.2. The logical endpoints are 10.0.1.126 and 10.0.1.254. Hosts on the left network have an entry in their routing table that specifies GW1 as the next hop for traffic addressed to the 10.0.1.128/25 network. Hosts on the right network have a similar entry in their routing table specifying GW2 as the next hop for the 10.0.1.0/25 network.

Figure 4.5. An IP-in-IP Tunnel

[View full size image]

When host H1 (10.0.1.1) wants to send a datagram to H129 (10.0.1.129), it first sends it to GW1because of the entry in the routing tablefrom which it is sent through the tunnel to GW2. When the encapsulated datagram reaches GW2, the outer IP header is stripped off, and the inner datagram is delivered to H129. Figure 4.6 shows this sequence of events for a ping packet sent from H1 to H129.

Figure 4.6. Packet Flow from H1 to H129

The specification for IP-in-IP tunnels is in RFC 2003 [Perkins 1996]. This RFC is interesting because it points out some of the problems with tunneling that an implementer must deal with. For example, adding the extra IP header will enlarge the total packet by at least 20 bytes. This may cause the packet to exceed the MTU of the interface, so the tunnel endpoint must be prepared to deal with fragmentation.

Now suppose that the original, inner, IP datagram had the don't-fragment (DF) bit set. RFC 2003 specifies that in that case, the tunnel endpoint must set the DF bit in the outer IP header also. Suppose that the size of the total datagram does not exceed the MTU of the tunnel endpoint but does exceed the MTU of a downstream router. Because the DF bit is set in the outer IP header, the router will send back an ICMP message indicating that fragmentation was required but that the DF bit was set. Recall from Chapter 2 that this ICMP message will contain the outer IP header and at least the first 8 bytes of the next header. In this case, those 8 bytes will be from the inner IP header, but as we see from Figure 2.11, that is not enough to determine the source address of the original IP datagram. Therefore, the tunnel endpoint will not be able, in general, to return the ICMP message to the originating host.

To solve this problem, RFC 2003 recommends that the tunnel endpoint maintain soft state concerning the path MTU of the tunnel. When the endpoint receives an ICMP message indicating that fragmentation is required, it updates its notion of the path MTU for the tunnel. Then if a host sends a datagram for the tunnel that exceeds its path MTU, the endpoint can return an ICMP message directly to the host because it has the entire original IP header, including the source address. RFC 2003 recommends that tunnel endpoints maintain soft state on at least

  • The MTU of the tunnel

  • The TTL of the tunnel (its total length in hops)

  • The reachability of the far endpoint

This soft state allows the tunnel endpoint to return the appropriate ICMP error message to the originating host while it still has the host's source address.


Section 4.3. PPPoE

4.3. PPPoE

The IP-in-IP tunnel that we studied in the previous section was an example of a network-layer protocol encapsulating another network-layer protocolindeed, the same network-layer protocol. In this section, we look at an example of tunneling an interface protocol in another interface protocol. Digital Subscriber Line (DSL) providers use the PPP over Ethernet (PPPoE) protocol to tunnel PPP over Ethernet links.

DSL modems are essentially simple Ethernet bridges that connect a remote site with access multiplexers (DSLAMs) at the telco central office, as shown in Figure 4.7. In order to manage DSL accounts and leverage their existing technology, ISPs often tunnel PPP over this Ethernet link.

Figure 4.7. Typical DSL Infrastructure

[View full size image]

The PPPoE protocol itself has two stages. In the first stage, PPPoE discovery, the clienta host or gateway on the customer's LANdiscovers the Ethernet MAC address of an access multiplexer willing to provide it service, and sets up the PPPoE tunnel. In the second stage, the PPP session, the client and DSLAM send normal PPP traffic through the tunnel.

Figure 4.8 shows the data flow for a typical PPPoE session. During the discovery stage, the Ethernet frames carry discovery packets that consist of a PPPoE header (Figure 4.10) and a payload for negotiating tunnel parameters. The Ethernet protocol field (ETHER_TYPE) is set to 0x8863 for these packets. The parameters are encoded tag-length-value triplets called TAGs. TAGs have the format shown in Figure 4.9. The type field identifies the type of tag, and the length field specifies the length in bytes of the value field that contains the TAG's value.

Figure 4.8. A Typical PPPoE Session

Figure 4.9. A PPPoE TAG

[View full size image]

The client first broadcasts a PPPoE active discovery initiation (PADI) packet. This packet specifies the service that the client is requestinga particular ISP, for exampleand any server willing to provide that service responds with a PPPoE active discovery offer (PADO) packet. The PADO packet contains the server's name, the service that the PADI packet specified, and any other services that the server can provide.

The client chooses one of the servers that responded with a PADO packet and sends it a PPPoE active discovery request (PADR) packet, again specifying the service it is seeking. If the service is acceptable to the server, it responds with a PPPoE active discovery session-confirmation (PADS) packet. The PADS packet specifies the service name that the client and server have agreed upon, and also sets the session ID.

At this point, the tunnel is established, and PPP can begin its LCP phase, as described in Chapter 2. When the client and server are finished with the tunnel, one side sends a PPPoE active discovery terminate (PADT) packet. This packet terminates the PPPoE session, and the tunnel is torn down.

Although not a product of the IETF, the PPPoE specification is documented in RFC 2516 [Mamakos, Lidl, Evarts, Carrel, Simone, and Wheeler 1999]. In addition to describing the discovery stage as we have here, the RFC describes the type and values of the TAGs used as discovery parameters.

The PPPoE header is shown in Figure 4.10. The ver and type fields are both set to 0x1.

Figure 4.10. The PPPoE Header

[View full size image]

The code field indicates the type of payload the PPPoE packet is carrying. These packet types are listed in Figure 4.11.

Figure 4.11. PPPoE Packet Types

Code

Packet Type

0x00

PPP session

0x09

PADI (initiation)

0x07

PADO (offer)

0x19

PADR (request)

0x65

PADS (session confirmation)

0xa7

PADT (terminate)

The session ID field contains a unique identifier that identifies the session. This field is set to 0 for the PADI, PADO, and PADR packets. The PPPoE server specifies the session ID in the PADS packet, and all packets for the remainder of the session must set the session ID to the same value.

The length field is the size in bytes of the packet payload. The length does not include the Ethernet or PPPoE headers.

The PPPoE encapsulation during the PPP session stage is shown in Figure 4.12.

Figure 4.12. PPPoE Encapsulation

[View full size image]

The Ethernet frame type is set to 0x8864 during the PPP session stage.

To see PPPoE in action, let's set up a PPPoE server on bsd and a PPPoE client on linux. We start the server on bsd with

bsd# /usr/libexec/pppoed -l pppoed -p pppoe dc1

The -p pppoe says that we will provide a service named pppoe, and the dc1 indicates that the server will listen for connections on the dc1 interface. The -l pppoed is the ppp.conf file label that specifies the parameters for the resulting PPP session when a client connects (Figure 4.13).

Figure 4.13. Part of the PPP Configuration File

[View full size image]

Most of these parameters simply set the default values for a PPPoE session. Lines 2627 disable address and control field compression, protocol field compression, and PPP payload compression. We turned off PPP payload compression in order to see the encapsulation when we watch the traffic with tcpdump. We disabled the other two compressions because the PPPoE specification either requires itaddress and control field compressionor recommends itprotocol field compression. The last line sets the IP addresses for the session. The server will have the address 10.0.0.1, and the client will have the address 10.0.0.2.

On linux, we start the PPPoE client with

linux:/home/jcs # pppd pty 'pppoe -I eth1 -S pppoe'

This line tells the PPP daemon, pppd, to run pppoe and communicate through it rather than a serial device. The -I eth1 in the pppoe call says to use the eth1 interface to locate a server, and the -S pppoe says to ask for service pppoe.

We run tcpdump on the dc1 interface of bsd to watch the traffic. First, linux looks for a PPPoE server by broadcasting a PADI packet:

1   16:58:55.686210 PPPoE PADI [Service-Name "pppoe"]
2   16:58:55.687648 PPPoE PADO [AC-Name "bsd"]
      [Service-Name "pppoe"] [AC-Cookie UTF8]
3   16:58:55.691609 PPPoE PADR [Service-Name "pppoe"]
      [AC-Cookie UTF8]
4   16:58:55.691630 PPPoE PADS [ses 0xb] [AC-Name "bsd"]
      [Service-Name "pppoe"] [AC-Cookie UTF8]

As expected from the -S pppoe in its invocation, the PPPoE client is looking for service pppoe.

On line 2, the server on bsd responds with a PADO packet offering to provide the pppoe service. Line 2 also gives the name of the server as bsdthe AC stands for access concentrator, another name for a DSLAMand sends a cookie that it uses to help prevent denial-of-service attacks.

The client accepts the offer on line 3 with its PADR packet. Notice that the client again specifies the service name it wants, because the server could have offered more than one service. The client also returns the cookie that the server sent in the PADO packet.

Finally, the server confirms the session on line 4 with its PADS packet. Notice that the server specifies the session ID as 0xb. At this point, the PPPoE session has been established, and the PPP negotiations can begin:

5   16:58:56.673573 PPPoE [ses 0xb] Conf-Req(1), ACCM=00000000,
      Magic-Num=4fef4ea8, PFC, ACFC
6   16:58:56.674455 PPPoE [ses 0xb] Conf-Req(1), MRU=1492,
      Magic-Num=2f01f605
                                       19 lines of PPP negotiation deleted
26  16:58:56.680379 PPPoE [ses 0xb] Conf-Ack(3), IP-Addr=10.0.0.2

Once the PPP session is established, we ping 10.0.0.2 from 10.0.0.1. This time, we ask tcpdump to show us the whole packet so that we can see the encapsulation:

27   16:59:05.206220 PPPoE [ses 0xb] 10.0.0.1 > 10.0.0.2:
      icmp: echo request
27.1    1100 000b 0056 0021 4500 0054 0a18 0000    .....V.!E..T....
27.2    4001 5c8f 0a00 0001 0a00 0002 0800 f44b    @.............K
27.3    4f02 0000 994a 5a3f d324 0300 0809 0a0b    O....JZ?.$......
27.4    0c0d 0e0f 1011 1213 1415 1617 1819 1a1b    ................
27.5    1c1d 1e1f 2021 2223 2425 2627 2829 2a2b    .....!"#$%&'()*+
27.6    2c2d 2e2f 3031 3233 3435 3637              ,-./01234567

The PPPoE header is set in boldface on line 27.1. As expected, the ver and type fields are both set to 0x1. The code is 0, indicating that this packet is carrying PPP session data (Figure 4.11). The length field is set to 86 (0x56), which is the default ping packet size of 84 plus two more for the PPP protocol field of 0x0021:

27.1    1100 000b 0056 0021 4500 0054 0a18 0000    .....V.!E..T....

Recall that a protocol of 0x0021 indicates that the PPP packet is carrying an IP datagram.

The rest of the packet is a normal ping packet, which we examined in Chapter 2. There is no HDLC framing: The address, control, and FCS fields are omitted. The first PPP field is the protocol field as shown in line 27.1.

After we finish with the ping, we shut down the PPPoE client on linux:

33   16:59:22.666941 PPPoE [ses 0xb] Term-Req(3)
34   16:59:22.668703 PPPoE [ses 0xb] Term-Ack(3)
35   16:59:22.740762 PPPoE PADT [ses 0xb]
       [Generic-Error "RP-PPPoE: System call error:
       Input/output error"] [AC-Cookie UTF8]
36   16:59:22.740799 PPPoE PADT [ses 0xb]
       [Generic-Error "session closed"]

The client sends a PPP session-terminate request, which the server ACKs, and then both sides send a PADT, which tears down the tunnel.

Many authorities believe that the PPPoE protocol has serious deficiencies involving robustness and securitysee [Carlson 2000] for a good summary of the typical complaintsand that in any event, its functions could be better handled by using existing protocols. Nevertheless, its use by DSL providers means that it's ubiquitous, and that implementers and system administrators will have to understand and deal with it.


Section 4.4. GRE

4.4. GRE

Protocols, such as IP-in-IP and PPPoE, must each have their own specification, and require encapsulation-specific processing code in the stacks that implement them. In general, if there are n protocols, there will be O(n2) encapsulations of the type protocol X over protocol Y. We can use Generic Routing Encapsulation (GRE) to reduce this to a more manageable size. The idea is that to tunnel protocol X over protocol Y, we would encapsulate as shown in Figure 4.14.

Figure 4.14. Using GRE to Encapsulate Protocol X in Y

[View full size image]

If we consider this from the point of view of the encapsulator, we immediately see the advantage. Rather than provide code to encapsulate protocol X in protocol Y for each protocol pair (X, Y), the encapsulating node provides a gre interfacesimilar to the FreeBSD gif interface we used for IP-in-IP encapsulationthat protocol X can be routed to. The gre interface performs any processing required by the GRE protocol, prepends the GRE header, and forwards the resulting packet to protocol Y for transmission. Similar steps take place at the other end of the tunnel: The protocol Y packet arrives and is forwarded to the gre interface, where the protocol X packet is decapsulated and forwarded to protocol X for further processing. The system administrator can configure the gre interface to encapsulate an arbitrary protocol, X, in another arbitrary protocol, Y.

The GRE header is shown in Figure 4.15. This format is specified by RFC 2784 [Farinacci, Li, Hanks, Meyer, and Traina 2000] and its extension, RFC 2890 [Dommety 2000]. These two RFCs largely recreated the specification of GRE given in the informational RFC 1701 [Hanks, Li, Farinacci, and Traina 1994].

Figure 4.15. The GRE Header

[View full size image]

The header shown in Figure 4.15 differs from that of RFC 1701 only in the absence of an optional routing field and valid bit, and a recursion control field that was used to indicate the number of additional encapsulations permitted. RFC 1701 also reserved, but did not define, a 5-bit flags field.

The C bit indicates that the checksum field is present and valid. When the C bit is set, the optional reserved1 field is also present. If the C bit is not set, the entire second 32-bit word of the header is not present.

The K bit indicates that the key field is present and valid. If the K bit is not set, the key field is not present in the header.

The S bit indicates that the sequence number field is present and valid. If the S bit is not set, the sequence number field is not present in the header.

The version field indicates the header version number. The header shown in Figure 4.15 is version 0. When GRE is used with PPTP (see Section 4.5), the key field is used for a different purpose, and an optional 32-bit acknowledgment field is added. In this case, the version field is set to 1.

The protocol type field contains the payload protocol type. These protocol types are the same as those used in the Ethernet protocol field. Thus, for example, IP has a protocol type of 0x0800. The complete, up-to-date list of these protocol numbers is available online from the Internet Assigned Numbers Authority (IANA) FTP server at <ftp://ftp.isi.edu/in-notes/iana/assignments/ethernet-numbers>.

The optional checksum field is present only when the C bit is set, in which case it contains the normal Internet checksum of the GRE header and its payload. When calculating the checksum, the checksum field is initially set to 0. When the checksum field is present, so is the reserved1 field.

The optional key field is present only when the K bit is set. This field is intended to identify a particular traffic flow within the tunnel. RFC 2890 leaves the exact semantics and structure of this field up to the implementer. As we mentioned earlier, PPTP has a completely different interpretation of this field.

The optional sequence number field is present only when the S bit is set. This field's intended use is to allow GRE to provide unreliable but in-sequence delivery of its payload packets. RFC 2890 specifies that the treatment of packets containing sequence numbers should be similar to that of IP packet fragment reassembly: Packets with sequence numbers that have already been received should be silently discarded; packets with a sequence number greater than that expected can be placed on a holding queue pending receipt of the missing packet or packets; packets on the holding queue should time out and be discarded after some interval, and the length of the holding queue should not be allowed to grow beyond a threshold size.

The Linux TCP/IP stack supports GRE tunnels through its ip command. To see how the configuration of such a tunnel would work and to see GRE encapsulation in action, let's configure a GRE tunnel between linuxlt and linux, as shown in Figure 4.16.

Figure 4.16. A GRE Tunnel

We first configure the tunnel on linuxlt, using the Linux ip command:

linuxlt: # ip tunnel add gretun mode gre remote 172.30.0.4
    local 172.30.0.15 key 0xaabbccdd
linuxlt: # ip link set gretun up
linuxlt: # ip addr add 192.168.123.1 dev gretun
linuxlt: # ip route add 192.168.122.0/24 dev gretun
linuxlt: # ping 192.168.122.1

The first line specifies that we want a GRE tunnel between linuxlt (172.30.0.15) and linux (172.30.0.4) with a key of 0xaabbccdd. This command creates an interface that we named gretun. Next, we configure the gretun interface up. This command is equivalent to the ifconfig command, which we could have used instead. The third line adds the address 192.168.123.1 to our gretun interface. Again, this is similar to the same operation using ifconfig. Finally, we add a route to the other end of the tunnel. We could have used the route command here instead.

We configure linux similarly and then ping linux from linuxlt. Here is the tcpdump output of the first ping and its reply:

1   15:30:17.466883 172.30.0.15 > 172.30.0.4: gre [Kv0] K:aabbccdd
    192.168.123.1 > 192.168.122.1: icmp: echo request (DF) (DF)
1.1    4500 0070 0d6b 4000 402f d4a4 ac1e 000f    E..p.k@.@/......
1.2    ac1e 0004 2000 0800 aabb ccdd 4500 0054    ............E..T
1.3    0d6a 4000 4001 b6eb c0a8 7b01 c0a8 7a01    .j@.@.....{...z.
1.4    0800 f8ac 420a 00b1 d934 4a40 a71f 0700    ....B....4J@....
1.5    0809 0a0b 0c0d 0e0f 1011 1213 1415 1617    ................
1.6    1819 1a1b 1c1d 1e1f 2021 2223 2425 2627    .........!"#$%&'
1.7    2829 2a2b 2c2d 2e2f 3031 3233 3435 3637    ()*+,-./01234567
2   15:30:17.469906 172.30.0.4 > 172.30.0.15: gre [Kv0] K:aabbccdd
    192.168.122.1 > 192.168.123.1: icmp: echo reply (DF)
2.1    4500 0070 0970 4000 402f d89f ac1e 0004    E..p.p@.@/......
2.2    ac1e 000f 2000 0800 aabb ccdd 4500 0054    ............E..T
2.3    096f 0000 4001 fae6 c0a8 7a01 c0a8 7b01    .o..@.....z...{.
2.4    0000 00ad 420a 00b1 d934 4a40 a71f 0700    ....B....4J@....
2.5    0809 0a0b 0c0d 0e0f 1011 1213 1415 1617    ................
2.6    1819 1a1b 1c1d 1e1f 2021 2223 2425 2627    .........!"#$%&'
2.7    2829 2a2b 2c2d 2e2f 3031 3233 3435 3637    ()*+,-./01234567

Line 1 shows a summary of the echo request: The IP datagram is from linuxlt (172.30.0.15) to linux (172.30.0.4). The datagram contains a version 0 GRE packet with the key field present ([Kv0]), and the key is 0xaabbccdd. The inner IP datagram is from the gretun interface on linuxlt (192.168.123.1) to the gretun interface on linux (192.168.122.1) and carries an ICMP echo request.

Let's look at the packet itself, so that we can see the encapsulation. The outer IP header is on lines 1.1 and 1.2:

1.1    4500 0070 0d6b 4000 402f d4a4 ac1e 000f    E..p.k@.@/......
1.2    ac1e 0004 2000 0800 aabb ccdd 4500 0054    ............E..T

The tenth byte is the protocol field (ip_p), which is set to 47 (0x2f), indicating GRE (see Figure 2.12). The source and destination addresses are 172.30.0.15 (0xac1e000f) and 172.30.0.4 (0xac1e0004).

Right after the outer IP header is the GRE header on line 1.2:

1.2    ac1e 000f 2000 0800 aabb ccdd 4500 0054    ............E..T

The 0x20 in the first byte shows that the K flag is set, indicating that the key field is present; the 0x00 in the second byte shows that this is version 0 of the GRE header. The next two bytes (0x0800) are the payload protocol type, indicating that the payload is another IP datagram. Because the C flag is not set, the optional checksum fields and the corresponding reserved field are not present. Next comes the key field, which is set to 0xaabbccdd, as expected. Because the S flag is not set, the optional sequence number field is not present, so the GRE header ends with the key field.

The remainder of the packet, on lines 1.21.7, is the encapsulated IP datagram. It is a normal ping packet from 192.168.123.1 (0xc0a87b01) to 192.168.122.1 (0xc0a87a01). The second packet is similar except that it is from linux to linuxlt, and the payload is an ICMP echo reply.

GRE is important for us because many tunnels and VPNs use it in their encapsulation. Indeed, Cisco tunnels use GRE by default. We shall see several examples of GRE encapsulations later in the text.


Section 4.5. PPTP

4.5. PPTP

A major problem faced by enterprises is that posed by the so-called road warrior. A typical example is a traveling sales representative who requires access to company inventory databases, order entry systems, and other servers located at the home office. One solution to this problem is shown in Figure 4.17. A remote user phones in to a remote access server (RAS), using, say, PPP to establish a connection to the home office's network.

Figure 4.17. Dialing in to the Home Network Through a RAS

[View full size image]

But this solution can be expensive. In the first place, the modem bank will have to be large enough to support the maximum number of simultaneous users. This equipment and the associated phone lines can represent a significant capital investment as well as recurring charges for the phone lines. In the second place, the remote user will, in general, incur long-distance charges.

Despite its expense, the RAS solution has certain advantages. It is more secure than simply connecting to the company network through the Internet. Although it is possible, of course, to tap phone lines, doing so is considerably more difficult than intercepting Internet traffic. Another problem with merely connecting through the Internet is that the remote host will not have an IP address that's on the company network, which can create problems, especially when the company network has a private (RFC 1918) address space. Observe how this problem is avoided with the RAS: Its PPP daemon can negotiate an address on the company network for the remote host.

In this section, we see how the Point-to-Point Tunneling Protocol (PPTP) offers a solution with the advantages of a RAS but without the associated expenses. We will ignore the security aspect for the time being and focus on the tunneling technology.

Architecturally, PPTP divides the RAS functions between a PPTP access concentrator (PAC) that remote users "dial" into, and a PPTP network server (PNS) that terminates remote clients' PPP sessions, provides access to the company network, and acts as a server for one or more PACs.

We put dial in quotes, because remote hosts can use other methods to connect to a PAC. Indeed, in the most common configuration, the PAC is built into the remote host, but even in this case, the remote user typically accesses the Internet through the phone system.

Functionally, the PAC-PNS pair provides a tunnel for PPP packets between the remote user and the PNS. PPTP itself runs between the PAC and the PNS; it does not involve the remote host, except when the PAC is part of the remote host, or the hosts on the company network. From the point of the remote host, using PPTP is identical to the RAS solution of Figure 4.17. The remote user places a (probably local) phone call and establishes a PPP session with the PNS, which provides access to the company network. The role of the PAC is to transfer PPP packets between the remote host and the PNS by sending them through the tunnel. The PAC does not take part in the PPP session itself.

As shown in Figure 4.18, each PAC-PNS pair has a tunnel between themthrough which they pass PPP packetsand a control connection that is used to manage the tunnel and establish PPP sessions between the remote host and the PNS.

Figure 4.18. A PAC-PNS Pair

The control connection is a TCP session that either the PAC or the PNS may initiate by connecting to port 1723 of its peer. The control connection state machine has a mechanism for resolving collisions in which the PAC and PNS attempt to connect to each other simultaneously.

The PAC and PNS communicate with each other over the control connection by exchanging PPTP control messages. These messages deal with control connection management, call management, error reporting, and certain PPP parameters. The general format of these messages is given in Figure 4.19.

Figure 4.19. PPTP Control Message Header

[View full size image]

The length field is the length of the entire PPTP message, including the header. The PPTP message type is always set to 1, indicating a control message. The protocol also provides for management messages (type 2), but they are not implemented or even defined.

The magic cookie always has the value 0x1a2b3c4d and is used for synchronization with the TCP data stream. If the second 32-bit word of the message does not have this value, the receiver knows that it has lost synchronization. In the event of desynchronization, the receiver can search for the magic cookie to resynchronize with the message boundaries.

The control message type field indicates the type of control message and the format of the rest of the message. The values of this field are listed in Figure 4.20.

Figure 4.20. PPTP Control Messages

Code

Message

Connection Control Management

1

Start-Control-Connection-Request

2

Start-Control-Connection-Reply

3

Stop-Control-Connection-Request

4

Stop-Control-Connection-Reply

5

Echo-Request

6

Echo-Reply

Call Management

7

Outgoing-Call-Request

8

Outgoing-Call-Reply

9

Incoming-Call-Request

10

Incoming-Call-Reply

11

Incoming-Call-Connected

12

Call-Clear-Request

13

Call-Disconnect-Notify

Error Reporting

14

WAN-Error-Notify

PPP Session Control

15

Set-Link_Info

The connection control management messages are used to set up, tear down, and test the connectivity of control connections. The typical case is for the PAC to send a Start-Control-Connection-Request to the PNS stating its desire to establish a control connection and listing its capabilities. The PNS replies with a Start-Control-Connection-Reply in which it lists its capabilities if it agrees to the connection, or gives a reason code for rejecting it.

During the life of the connection, either side can send the other an Echo-Request if it has not received other traffic for a specified time. If the other side does not respond with an Echo-Reply, the sender closes the control connection.

Either side can initiate connection teardown by sending its peer a Stop-Control-Connection-Request. The peer responds with a Stop-Control-Connection-Response either agreeing to the request or giving an error code specifying why it cannot comply. Closing the control connection will also cause the tunnel to be torn down, terminating any active PPP sessions.

The tunnel is a GRE tunnel that encapsulates the PPP packets, as shown in Figure 4.21. The remote host passes the PPP packet to the PAC, which adds GRE and IP headers and sends them over the Internet to the PNS. The PNS removes the GRE and IP headers and passes the PPP packet to its PPP daemon. If the PPP packet is carrying network-layer data, PPP removes the datagram and forwards it to the company network.

Figure 4.21. PPP Packets Tunneled in the PPTP GRE Tunnel

[View full size image]

As we mentioned earlier, PPTP uses an extended (version 1) GRE header. As we see in Figure 4.22, this header has an additional acknowledgment number field and corresponding A bit to indicate whether it is present. The interpretation of the key field is different. It is divided into a payload length field that contains the length of the payload, not including the GRE header, and a call ID field that is used to demultiplex the PPP connection.

Figure 4.22. The PPTP Extended GRE Header

[View full size image]

Figure 4.23 shows PPTP tunneling in a typical situation. The upper PAC is a dial-in facilityat an ISP, saythat remote users connect to using PPP. This is called mandatory mode because the remote hosts have no say in whether their connections are tunneledindeed, they will usually be unaware of the tunneling. Several remote hosts can share the PAC and its tunnel: The figure shows n hosts connected to the PAC and passing PPP packets through its tunnel. The PAC does not deal with the PPP datagrams in any way other than sending them through the tunnel to the PNS.

Figure 4.23. PPTP Mandatory and Voluntary Modes

[View full size image]

The lower PAC is built into the remote host itself. In this case, the PPTP tunnel extends all the way to the remote host. This is called voluntary mode because the remote host is directly involved with the mechanics of the tunnel and must elect to use it. This is not the case with the upper PAC.

When a remote host connects to a PAC, either by dialing in or internally when the PAC is built in, the PAC sends the PNS an Incoming-Call-Request with details about the source of the call. The PNS responds with an Incoming-Call-Reply either accepting the call or an error code specifying the reason for rejecting it. If it accepts the call, the PNS also responds with some information about its receive window and the processing delay that it expects will apply to PPP packets during the session.

When the PAC receives the Incoming-Call-Reply, it can answer the remote host's call. Once the PAC has accepted the remote host's call, it has additional information, such as the type of connection, line speed, receive window, and processing delay, that it can pass to the PNS. Therefore, the PAC completes the session-establishment handshake by sending the PNS an Incoming-Call-Connected message with these parameters. At this point, the remote host and PNS begin their PPP LCP negotiation.

At any time during the session, the PNS can send a Call-Clear-Request to the PAC, asking it to terminate the call. The PAC will disconnect the call and inform the PNS it has done so with a Call-Disconnect-Notify. The PAC will also send the PNS a Call-Disconnect-Notify if the remote host disconnects on its own.

The PNS can initiate an outbound call to a remote host by sending the PAC an Outgoing-Call-Request. The PAC will respond with an Outgoing-Call-Reply either indicating that the connection was established or giving an error code specifying why it couldn't connect to the remote host.

If, during the session, the PAC experiences an error on the WAN (Internet) connection, it will send the PNS a WAN-Error-Notify message. This message contains a set of cumulative error counters for CRC, framing, hardware overruns, buffer overruns, timeout, and alignment errors. This message is sent only when an error occurs and never more than once a minute.

Although we have concentrated on the tunneling aspects of PPTP, its real use is as a VPN in Microsoft networks. We revisit PPTP in Chapter 5, where we discuss PPTP's VPN properties.

Because most experts discourage the use of PPTP, and because Microsoft now uses the Layer Two Tunneling Protocol (L2PT) as the primary type of VPN in Microsoft networks, we have omitted some of the details of the protocol and the control message formats here. Complete details are available in RFC 2637 [Hamzeh, Pall, Verthein, Taarud, Little, and Zorn 1999].


Section 4.6. L2TP

4.6. L2TP

PPTP uses TCP for its control channel, restricting its use to IP networks. To overcome this limitation, Cisco developed a proprietary protocol called Layer Two Forwarding (L2F), which was similar to PPTP but could operate over any link-layer protocol. The IETF combined ideas from PPTP and L2F to produce a third protocol, called the Layer Two Tunneling Protocol (L2TP).

Like PPTP, the goal of L2TP is to split the functions of the RAS shown in Figure 4.17 into two parts: an L2TP access concentrator (LAC) that handles the physical communication to the remote host, and an L2TP network server (LNS) that terminates the remote host's PPP session and acts as a gateway into the private network.

As with PPTP, L2TP can operate in mandatory mode, in which the remote host connects to a stand-alone LAC, or in voluntary mode, in which the LAC resides on the remote host itself. Unlike PPTP, there is no separate control connection between the LAC and LNS. Rather, control information is sent through the tunnel itself. These features are illustrated in Figure 4.24. The similarity to Figure 4.23 is clear.

Figure 4.24. L2TP Mandatory and Voluntary Modes

[View full size image]

Despite the fact that we labeled the mandatory mode connections as PPP dial-in, L2TP allows for other types of connections as well. For example, the LAC might sit on a LAN and act as a gatewayin conjunction with its associated LNSto a geographically remote private network.

Although we focus on the use of L2TP in IP networks, it's important to be aware that L2TP can run on other types of networks as well. That, after all, is why the control connection was made to be independent of TCP. As with the other protocols we have studied in this chapter, we limit our discussion to the tunneling aspects of L2TP, but like PPTP, L2TP finds its main use as a VPN.

Before looking at the operation of the protocol, let's examine its encapsulation in IP networks. Instead of using GRE to encapsulate the PPP frames as PPTP does, L2TP uses UDP datagrams, much as we did in Figure 4.2 and Figure 4.3. The encapsulation, shown in Figure 4.25, includes an L2TP header that contains session information used to demultiplex the PPP frames.

Figure 4.25. L2TP in IP/UDP Encapsulation

[View full size image]

Using UDP rather than GRE to encapsulate the L2TP messages makes it easier for L2TP to interoperate with NAT devices. Recall that the most popular mode of NAT is port address translation (PAT), where the port addresses are used to map datagrams to the proper hosts. The problem with using GRE, as PPTP does, is that the GRE header has no port addresses for PAT to use. With UDP, on the other hand, the port addresses are available, and NAT is able to interoperate with L2TP.

The L2TP Header

There are two types of messages streams within an L2TP tunnel:

  1. A single control connection that is used to establish and manage the L2TP tunnel itself, and to initiate and terminate user sessions. These messages are called control messages.

  2. One or more user connections that carry the PPP frames from the remote host to the LNS. These are called data messages.

Both types of messages start with the common header shown in Figure 4.26.

Figure 4.26. The L2TP Common Header

[View full size image]

This header is extensible in two ways. First, several of the fields are optional. Second, additional fields are added to the common header, depending on what type of information the message is carrying. These additional fields are in the form of a type-length-value triplet called an attribute value pair (AVP). Functionally, AVPs are similar to IP or TCP options: A set of AVPs is appended to the common header to carry additional information specific to the particular type of message. As we shall see, there is a mechanism to allow proprietary extensions as well. We'll look at the general format of an AVP shortly.

The T bit is used to distinguish control messages from session messages. The T bit is set for control messages and cleared for session messages.

The L bit is used to signal the presence of the length field. The L bit is always set for control messages, and is optional for data messages. A sender who determines that a length field is not required can omit it and clear the L bit.

The S bit signals the presence of the sequence number fields: Ns and Nr. These fields are always present for control messages, so the S bit is always set for control messages. Data messages can also use the sequence number fields to detect lost and out-of-order messages. If the data session does use sequence numbers, the peers will set the S bit.

The O bit indicates whether the offset field is present. The O bit is always cleared for control messages.

The P bit indicates that the message should be given priority for queuing and transmission on the local machine. The L2TP keep-alive messages, described later, are an example of a message that can make use of the P bit. The P bit is always cleared for control messages.

The version field is always set to 2 for L2TP messages. The value 1 is used for L2F messages in order to provide backward compatibility with L2F.

The length field, when present, specifies the total length of the message, including the header. When the length field is present, the maximum-length message, including the header, is 65,535 bytes. When the length field is not present, there is no maximum length for L2TP messages, but on IP networks, the 16-bit IP length field will limit the size of the message, whether or not the L2TP length field is present, to 65,527 bytes.

The tunnel ID field identifies a particular tunnel. Each peer has its own value for this field. When peer A sends a message to peer B, A will set this field to B's value so that B can identify the tunnel instance. That is, the sender always uses the receiver's tunnel ID, not its own.

The session ID field identifies the particular session that a data message belongs to. This field will be 0 for control messages and for the initial message in the session establishment handshake. As with the tunnel ID field, each peer will have its own value for the session ID of a particular session, and the sender will always use the receiver's value.

The Ns and Nr fields play a role similar to that of the TCP sequence number and ACK fields. When sequence numbers are in use, each message that a peer sends has a sequence number in the Ns field. The first message has Ns set to 0, and each subsequent message increments its value by 1 (modulo 216). Because control messages always use sequencing, they will always have this field present. Data messages will have an Ns field if sequencing is in use, as indicated by the S bit.

The Nr field acts exactly like the TCP ACK field: Its value is the sequence number of the next message the sender is expecting from its peer. Like the TCP ACK field, the Nr field implicitly acknowledges receipt of all messages with a lower sequence number. The Nr field is used only by control messages; receivers must ignore it if it is present in data messages.

As with TCP sequence numbers, the definition of lower sequence number is complicated by the fact that the sequence numbers can wrap. Assuming a 32-bit machine, we might define the macro

#define SEQ_LT(a,b) ((short)((a)-(b))<0)

to check for a < b, where a and b are unsigned short integers. The SEQ_LT macro is derived directly from the BSD TCP/IP macro of the same name by using shorts instead of integers.

The offset size and offset pad fields are used to pad the header for alignment purposes. When present, as indicated by the O bit, the offset size specifies the number of bytes after the offset-size field where the data starts. The contents of the pad field are undefined, and although it's not shown in Figure 4.26, it can extend beyond 2 bytes. Control messages never have either of these two fields present.

Attribute Value Pairs

Fields in control messages other than those in the common header of Figure 4.26 are carried as attribute value pairs that immediately follow the common header. AVPs have the form shown in Figure 4.27.

Figure 4.27. L2TP Attribute Value Pair

[View full size image]

The M bit field indicates that this AVP is mandatory. That is, the receiver must recognize this field or terminate the current operation. For messages associated with a data session, the session must be torn down. If the message is associated with the tunnel itself, the tunnel and all its sessions must be terminated. If the M bit is not set and the receiver does not recognize the AVP, the receiver must ignore the AVP and continue processing as if it had not received the AVP.

The H bit, or hidden bit, is used to indicate that this AVP is encrypted. Hidden AVPs are useful for transmitting passwords and other sensitive parameters. We discuss how to perform this encryption shortly.

The length field is the number of bytes in the AVP, including the bits and length field. The minimum length is thus 6 bytes when there is no attribute value.

The vendor ID field is another mechanism to facilitate extensibility. When the vendor ID is 0, the attribute type values are those defined in the L2TP specification, RFC 2661 [Townsley, Valencia et al. 1999]. Vendors can obtain a vendor ID from the IETF and define their own proprietary attribute types. In this case, the vendor ID would be nonzero, and the interpretation of the attribute type field would depend on the vendor-defined values and associated semantics.

The attribute type field is a 16-bit integer specifying what parameter this AVP is carrying. We discuss several of the attributes here. A complete list is available in RFC 2661. The value, if any, of the parameter is in the attribute value field. The value is l 6 bytes long, where l is the number in the length field.

Encryption of AVPs

In order for encryption to take place, the LAC and LNS must have a shared secret. Next, a message that has a hidden AVP must also have a random vector AVP that precedes the hidden AVP. The random vector is used as part of the key for the encryption process. Once these two things are in place, we can begin the encryption.

First, the AVP is encoded as shown in Figure 4.28.

Figure 4.28. Hidden AVP Encoding

[View full size image]

The original length field contains the length of the original value field, which will be obscured by the padding and encryption. An arbitrary amount of padding can be added to the original value to hide its original length. The original length field is used by the receiver to discard this padding.

The final AVP is shown in Figure 4.29, with the encrypted portion shaded.

Figure 4.29. A Hidden AVP

[View full size image]

Only the encoding shown in Figure 4.28 is encrypted; the remainder of the AVP is in plaintext so that the receiver can process it correctly.

The encryption is performed by concatenating

  1. The 2-byte attribute type

  2. The shared secret

  3. The arbitrary-length random vector

and taking an MD5 hash of the result. The MD5 operation yields 16 bytes that are exclusive-ORed into the encoding of Figure 4.28. If more than 16 bytes are required, additional key stream is generated by concatenating the shared secret with the result of the previous exclusive-OR operation and taking an MD5 hash of the result. This operation is repeated until enough key stream is generated to completely encrypt the original value and its length.

If we let R be the random vector, S the shared secret, and T the attribute type, and if we think of the original value and its length as consisting of 16-byte blocks B0, . . . , Bn, we can summarize this as

K0 = MD5(T || S || R) | C0 = B0 [image] K0
K1 = MD5(S || C0) | C1 = B1 [image] K1
... |
Kn = MD5(S || Cn-1) | Cn = Bn [image] Kn

where the [image] Ci [image] are the encrypted 16-byte blocks corresponding to the plaintext blocks [image] Bi [image].

If more than one hidden AVP is in a message, they may use the same random vector, or the sender can transmit multiple random vectors. If there is more than one random vector, a hidden AVP must use the nearest preceding random vector.

Control Messages

Fourteen control messages are used for the establishment and management of the L2TP tunnel and its sessions. These messages are listed in Figure 4.30.

Figure 4.30. L2TP Control Messages

Code

Message

Description

Control Connection Management

1

SCCRQ

Start-Control-Connection-Request

2

SCCRP

Start-Control-Connection-Reply

3

SCCCN

Start-Control-Connection-Connected

4

StopCCN

Stop-Control-Connection-Notification

6

HELLO

Hello

Call Management

7

OCRQ

Outgoing-Call-Request

8

OCRP

Outgoing-Call-Reply

9

OCCN

Outgoing-Call-Connected

10

ICRQ

Incoming-Call-Request

11

ICRP

Incoming-Call-Reply

12

ICCN

Incoming-Call-Connected

14

CDN

Call-Disconnect-Notify

Error Reporting

15

WEN

WAN-Error-Notify

PPP Session Control

16

SLI

Set-Link-Info

The common header (Figure 4.26) does not have a message type field, so an AVP (attribute type 0) is used to identify the type of message. This 8-byte AVP must always be the first AVP in a control message. The message type (from Figure 4.30) is carried in the 2-byte value field, as shown in Figure 4.31. The message type AVP is mandatory and not hidden. Except in the case of a zero-length body (ZLB) message, which is used as an ACK, the message type AVP must always be present.

Figure 4.31. The Message Type AVP

[View full size image]

A Typical L2TP Session

So that we will have a concrete example to discuss and analyze, let's capture a typical L2TP session with tcpdump. This session is between linuxlt, playing the part of the LAC, and linux, acting as the LNS. The network configuration is shown in Figure 4.32.

Figure 4.32. Test Network for an L2TP Session

The L2TP tunnel, shown shaded in the figure, carries L2TP messages in UDP datagrams over the 172.30.0.0/24 network. The LNS acts as a gateway into the 192.168.122.0/24 network. Although linuxlt is not directly connected to the 192.168.122.0/24 network, the L2TP tunnel provides a virtual extension of that network to linuxlt, as shown by the dashed line.

Here is a tcpdump of the session:

1  15:17:47.532030 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0)
    *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(1680)
    *HOST_NAME(eriwan) VENDOR_NAME(l2tpd.org)
    *ASSND_TUN_ID(48224) *RECV_WIN_SIZE(4) (DF)
2  15:17:47.576801 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[TLS](48224/0)Ns=0,Nr=1 *MSGTYPE(SCCRP)
    *RANDOM_VECTOR(d3a7909125f5c53e58f869c079868059)
    *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(1680)
    *HOST_NAME(eriwan) VENDOR_NAME(l2tpd.org) *ASSND_TUN_ID(52379)
    *RECV_WIN_SIZE(4) (DF)
3  15:17:47.578062 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[TLS](52379/0)Ns=1,Nr=1 *MSGTYPE(SCCCN) (DF)
4  15:17:47.583876 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[TLS](48224/0)Ns=1,Nr=2 ZLB (DF)
5  15:18:08.255780 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[TLS](52379/0)Ns=2,Nr=1 *MSGTYPE(ICRQ)
    *ASSND_SESS_ID(40607) *CALL_SER_NUM(3) *BEARER_TYPE() (DF)
6  15:18:08.259860 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[TLS](48224/40607)Ns=1,Nr=3 *MSGTYPE(ICRP)
    *RANDOM_VECTOR(4890def0d66a88ed4db0473642debca1)
    *ASSND_SESS_ID(20575) (DF)
7  15:18:08.260005 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[TLS](52379/20575)Ns=3,Nr=2 *MSGTYPE(ICCN)
    *TX_CONN_SPEED(10000000) *FRAMING_TYPE(S)
    *RX_CONN_SPEED(10000000) (DF)
8  15:18:08.266317 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[](52379/20575) {Conf-Req(1), ACCM=00000000,
    Magic-Num=c49a6f1e, PFC, ACFC} (DF)
9  15:18:08.294282 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[TLS](48224/0)Ns=2,Nr=3 ZLB (DF)
10 15:18:08.321691 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[TLS](48224/40607)Ns=2,Nr=4 ZLB (DF)
11 15:18:08.332097 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[L](48224/40607) {Conf-Req(1), ACCM=00000000,
    Magic-Num=c49a6f1e, PFC, ACFC} (DF)
                                      additional PPP negotiation deleted
12 15:18:47.603327 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[TLS](48224/0)Ns=2,Nr=5 *MSGTYPE(HELLO) (DF)
13 15:18:47.609330 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[TLS](52379/0)Ns=5,Nr=3 ZLB (DF)
14 15:19:07.189282 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[](52379/20575) {192.168.122.2 > 192.168.122.1:
    icmp: echo request (DF)} (DF)
15 15:19:07.193070 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[L](48224/40607) {192.168.122.1 > 192.168.122.2:
    icmp: echo reply} (DF)
                                      L2TP and PPP hellos deleted
16 15:19:55.713922 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[TLS](52379/20575)Ns=6,Nr=4 *MSGTYPE(CDN)
    *RESULT_CODE(1/0 Bad file descriptor)
    *ASSND_SESS_ID(40607) (DF)
17 15:19:55.717628 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[TLS](48224/40607)Ns=4,Nr=7 ZLB (DF)
18 15:20:16.441387 172.30.0.15.1701 > 172.30.0.4.1701:
    l2tp:[TLS](52379/0)Ns=7,Nr=4 *MSGTYPE(StopCCN)
    *ASSND_TUN_ID(48224) *RESULT_CODE(1/0 Goodbye!)  (DF)
19 15:20:16.444907 172.30.0.4.1701 > 172.30.0.15.1701:
    l2tp:[TLS](48224/0)Ns=4,Nr=8 ZLB (DF)

The session begins on lines 14 with linuxlt, acting as the LAC, establishing a tunnel to linux. After tunnel establishment, linuxlt initiates a data session on lines 57, followed by the PPP negotiation starting on line 8. In lines 1619, the data session and tunnel are torn down. We look at each of these phases in greater detail shortly.

Tunnel Establishment

As with PPTP, either the LAC or the LNS can initiate a tunnel. If both sides attempt to initiate a tunnel at the same time, a tie-breaking mechanism lets one side proceed as the initiator and the other side take the role of the responder. Figure 4.33 shows the typical case of a LAC initiating a tunnel to the LNS.

Figure 4.33. Tunnel-Initiation Handshake

The three-message process is reminiscent of the TCP's three-way connection establishment handshake. In the first message, the initiator sends a Start-Control-Connection-Request message. The SCCRQ message contains several AVPs, some of which are optional. The AVPs are shown in Figure 4.34.

Figure 4.34. SCCRQ AVPs

AVP

Attribute
Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

protocol version

2

8

1

0

•

framing capabilities

3

10

1

•

bearer capabilities

4

10

1

tie breaker

5

14

0

0

firmware revision

6

8

0

host name

7

var

1

0

•

vendor name

8

var

0

assigned tunnel ID

9

8

1

•

receive window size

10

8

1

0

challenge

11

var

1

random vector

36

var

1

0

Many of the AVPs in Figure 4.34 are self-explanatory. Recall that the length of the value field of an AVP is l 6, where l is the length given in the table. Note that the lengths are before any hiding.

The meaning of the M bit is special for the message type AVP. Rather than indicating that the AVP itself must be recognized, the M bit indicates that the message must be recognized. If the M bit of message type AVP is set and the receiver does not recognize the message, the tunnel must be torn down. If the M bit is cleared and the receiver does not recognize the message, the receiver can ignore the message. Note that all the messages in Figure 4.30 will have the M bit of the message type AVP set.

The protocol version value field comprises 2 bytes. The most significant byte is the version, which is set to 1. The low-order byte is the revision, which is set to 0. Note that this field is not the same as the version field in the common header.

The framing capabilities AVP is a 32-bit mask. The lowest-order bit is set if the sender is capable of using synchronous framing. The next-lowest-order bit is set if the sender is capable of asynchronous framing.

The bearer capabilities field is also a 32-bit mask. The lowest-order bit is set if the sender supports digital access. The second-lowest-order bit is set if the sender supports analog access.

The tie breaker is a 64-bit random value used to resolve the conflict that arises when both the LAC and LNS try to initiate a tunnel at the same time. When one side receives an SCCRQ, that side must check whether it has also initiated a tunnel. If so, the receiver compares its tie-breaker value with that of its peer. The side with the lower value proceeds with its tunnel, and the other side abandons its tunnel.

The assigned tunnel ID is used to demultiplex messages for multiple tunnels. The sender expects its peer to set the tunnel ID field of the common header to this value for all messages that the peer sends to it. The tunnel ID field in the common header will be 0 for the SCCRQ message.

The receive window size AVP indicates how many unacknowledged control messages may be outstanding to the sender. If this AVP is missing, the peer must assume a value of 4.

If the sender of the SCCRQ wishes to authenticate its peer with a CHAP-like mechanism (RFC 1994 [Simpson 1996]), it can include the challenge AVP. The value field of this AVP is an arbitrarily long sequence of random bytes.

As we discussed previously, whenever a hidden AVP is included in a message, that AVP must be preceded by a random vector AVP that contains an arbitrarily long sequence of random bytes.

The receiver of the SCCRQ message will respond with a Start-Control-Connection-Reply (SCCRP) message, indicating that it will accept the connection and specifying its connection parameters.

If the peer refuses to accept the connection, it will respond with a StopCCN message. This message contains a result code specifying the reason for rejecting the connection.

The AVPs in the SCCRP message are the same as those in the SCCRQ message (Figure 4.34), with the addition of a challenge response, as shown in Figure 4.35.

Figure 4.35. SCCRP AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

Same as those for SCCRQ

challenge response

13

22

1

The value of the challenge response is computed by taking an MD5 hash of the message type (2 for SCCRP), the shared secret, and the challenge value:

CR = MD5(T || S || C)

where T is the message type, S is the shared secret, C is the challenge value, and CR is the challenge response.

If the parameters in the SCCRP message are acceptable to the tunnel initiator, it will complete the tunnel establishment by sending its peer a Start-Control-Connection-Connected (SCCCN) message.

If the parameters are not acceptable, it will respond with a StopCCN message.

The SCCCN message has one required and two optional AVPs, as shown in Figure 4.36.

Figure 4.36. SCCCN AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

challenge response

13

22

1

random vector

36

var

1

0

Once the responder receives the SCCCN message, the tunnel is established. At that point, either side can request that a PPP session between a remote host and the LNS be started.

Either side can reject the connection by sending a StopCCN message. This message is also used to tear down the tunnel when one or both of the peers are finished with it. The StopCCN message has three required and one optional AVP, as shown in Figure 4.37.

Figure 4.37. StopCCN AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

result code

1

var

1

0

•

assigned tunnel ID

9

8

1

•

random vector

36

var

1

0

The result code AVP is formatted as shown in Figure 4.38.

Figure 4.38. The Result Code AVP

[View full size image]

The length field indicates whether the optional fields are present. The 2-byte result code is always present. The values defined for the StopCCN message are shown in Figure 4.39.

Figure 4.39. StopCCN Result Codes

Code

Meaning

0

reserved

1

general request to clear control connection

2

general errorerror code indicates problem

3

control channel already exists

4

requester not authorized

5

bad protocol versionerror code indicates highest version supported

6

requester is being shut down

7

finite state machine error

The error code field contains additional information about the result code values. When the result code indicates a general error (1), the error code tells us what the particular error is. Its values are given in Figure 4.40.

Figure 4.40. Error Codes

Code

Meaning

0

no error

1

no control connection exists for the LAC/LNS pair

2

incorrect length

3

field value out of range or reserved field nonzero

4

insufficient resources

5

invalid session ID

6

vendor-specific error (see error message field)

7

try another LNS

8

unknown AVP with M bit set (see error message field for AVP type)

The error message field contains a human-readable string that provides further information about the error code. This field is not present unless the error code field is. Thus the receiver can unambiguously determine which fields are present, by examining the AVP length field.

Let's look again at our sample L2TP session to see these messages in action. Here, in greater detail, are the first four messages from the session:

1   15:17:47.532030 172.30.0.15.l2f > 172.30.0.4.l2f:
     l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0)
     *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(1680)
     *HOST_NAME(eriwan) VENDOR_NAME(l2tpd.org)
     *ASSND_TUN_ID(48224) *RECV_WIN_SIZE(4) (DF)
1.1    4500 007f 17f8 4000 4011 ca26 ac1e 000f    E.....@.@..&....
1.2    ac1e 0004 06a5 06a5 006b 74c4 c802 0063    .........kt....c
1.3    0000 0000 0000 0000 8008 0000 0000 0001    ................
1.4    8008 0000 0002 0100 800a 0000 0003 0000    ................
1.5    0003 800a 0000 0004 0000 0000 0008 0000    ................
1.6    0006 0690 800c 0000 0007 6572 6977 616e    ..........eriwan
1.7    000f 0000 0008 6c32 7470 642e 6f72 6780    ......l2tpd.org.
1.8    0800 0000 09bc 6080 0800 0000 0a00 04      ......'........
2   15:17:47.576801 172.30.0.4.l2f > 172.30.0.15.l2f:
     l2tp:[TLS](48224/0)Ns=0,Nr=1 *MSGTYPE(SCCRP)
     *RANDOM_VECTOR(d3a7909125f5c53e58f869c079868059)
     *PROTO_VER(1.0) *FRAMING_CAP(AS) *BEARER_CAP() FIRM_VER(1680)
     *HOST_NAME(eriwan) VENDOR_NAME(l2tpd.org) *ASSND_TUN_ID(52379)
     *RECV_WIN_SIZE(4) (DF)
2.1    4500 0095 aa5f 4000 4011 37a9 ac1e 0004    E...._@.@.7.....
2.2    ac1e 000f 06a5 06a5 0081 f0ce c802 0079    ...............y
2.3    bc60 0000 0000 0001 8008 0000 0000 0002    .'..............
2.4    8016 0000 0024 d3a7 9091 25f5 c53e 58f8    .....$....%..>X.
2.5    69c0 7986 8059 8008 0000 0002 0100 800a    i.y..Y..........
2.6    0000 0003 0000 0003 800a 0000 0004 0000    ................
2.7    0000 0008 0000 0006 0690 800c 0000 0007    ................
2.8    6572 6977 616e 000f 0000 0008 6c32 7470    eriwan......l2tp
2.9    642e 6f72 6780 0800 0000 09cc 9b80 0800    d.org...........
2.10   0000 0a00 04                               .....
3   15:17:47.578062 172.30.0.15.l2f > 172.30.0.4.l2f:
     l2tp:[TLS](52379/0)Ns=1,Nr=1 *MSGTYPE(SCCCN) (DF)
3.1    4500 0030 17fb 4000 4011 ca72 ac1e 000f    E..0..@.@..r....
3.2    ac1e 0004 06a5 06a5 001c 855c Bc802 0014   ...............
3.3    cc9b 0000 0001 0001 8008 0000 0000 0003    ................
4   15:17:47.583876 172.30.0.4.l2f > 172.30.0.15.l2f:
     l2tp:[TLS](48224/0)Ns=1,Nr=2 ZLB (DF)
4.1    4500 0028 aa60 4000 4011 3815 ac1e 0004    E..(.'@.@.8.....
4.2    ac1e 000f 06a5 06a5 0014 15ba c802 000c    ................
4.3    bc60 0000 0001 0002 0000 0000 0000         .'............

As we see, linuxlt initiates tunnel establishment with an SCCRQ message. The first 20 bytes are the IP header, which is followed by the 8 bytes of the UDP header. We see from these headers that the message is from 172.30.0.15 (0xac1e000f) to 172.30.0.4 (0xac1e0004) and that the source and destination ports are both 1705 (0x06a5).

Next comes the L2TP header (Figure 4.26), shown in boldface on lines 1.2 and 1.3. The first 8 bits tell us that the T, L, and S flags are set. The L2TP version is 2, as expected. The next 2 bytes tell us that the length of the L2TP message is 99 (0x63) bytes long. No tunnel or session ID has been established yet, so these two fields are zeroed. Finally, we see that Ns and Nr are both 0 as well.

The first AVP, the message type, immediately follows the header in the last 8 bytes of line 1.3. We see that the M bit is set, indicating that our peer must recognize this message type, and that the AVP is 8 bytes long. Because this is a standard AVP, the vendor ID field is 0. The attribute type is 0, indicating that this is the message type AVP (Figure 4.34), and the message type is 1, indicating an SCCRQ message (Figure 4.30).

The next AVP starts 8 bytes after the first byte of the message type AVP. We see that its attribute type is 2, which, from Figure 4.34, specifies the protocol version. We can step through the remaining AVPs in a similar fashion to verify the information that tcpdump printed out in line 1.

The tcpdump output is particularly informative for L2TP messages. The bracketed letters (TLS in the SCCRQ message) indicate the bits set in the L2TP header. Because the O and P bits are not set, the offset size and offset pad fields are not present. Next comes the local tunnel and session IDs in parentheses, followed by the Ns and Nr values (when the S bit is set). Finally, the AVPs and their values are listed. The asterisk in front of an AVP indicates that the M bit is set.

Because tcpdump provides comprehensive information about L2TP messages, we needn't bother analyzing the remaining hex dumps in detail. It is an excellent exercise, however, to verify the details that tcpdump prints out for one or two of the other messages. Doing so results in a deeper understanding of how the protocol works and how its messages are formed.

Before leaving the SCCRQ message, we should note an anomaly with the host name AVP. As shown on line 1, linuxlt sent a host name of eriwan. This is because of a bug in the L2TP software used for the session. Instead of using the configured name, it always uses the hard-coded name eriwan.

The second message shows linux responding to the SCCRQ with an SCCRP. The tunnel ID field is filled in with 48224 because its value is known from the assigned tunnel ID AVP in the SCCRQ message. The session ID is still 0, of course, because no sessions are active.

We note that linux sets its tunnel ID to 52379. This is the value that linuxlt will put in the tunnel ID field, as we'll see in the next message.

We also see that Nr is set to 1. This indicates that linux expects the Ns value of the next message from linuxlt to be set to 1.

Although it is not used, linux provides a random vector AVP. Sending this AVP when it's not needed is a peculiarity of this implementation. The rest of the AVPs are similar to those in the SCCRQ message.

The tunnel establishment is completed with the next message, in which linuxlt sends an SCCCN message. Because it doesn't have a message pending for linuxlt, linux responds to the SCCCN with a ZLB. This corresponds to TCP's pure ACK message and is sent as part of the tunnel-reliability mechanism. The ZLB plays no part in tunnel establishment.

Lines 18 and 19 from the sample session show what happens when the peers are finished with the tunnel:

18    15:20:16.441387 172.30.0.15.l2f > 172.30.0.4.l2f:
        l2tp:[TLS](52379/0)Ns=7,Nr=4 *MSGTYPE(StopCCN)
        *ASSND_TUN_ID(48224) *RESULT_CODE(1/0 Goodbye!) (DF)
18.1      4500 004a 1856 4000 4011 c9fd ac1e 000f    E..J.V@.@.......
18.2      ac1e 0004 06a5 06a5 0036 4a0f c802 002e    .........6J.....
18.3      cc9b 0000 0007 0004 8008 0000 0000 0004    ................
18.4      8008 0000 0009 bc60 8012 0000 0001 0001    .......'........
18.5      0000 476f 6f64 6279 6521                   ..Goodbye!
19    15:20:16.444907 172.30.0.4.l2f > 172.30.0.15.l2f:
        l2tp:[TLS](48224/0)Ns=4,Nr=8 ZLB (DF)
19.1      4500 0028 aabb 4000 4011 37ba ac1e 0004    E..(..@.@.7.....
19.2      ac1e 000f 06a5 06a5 0014 15b1 c802 000c    ................
19.3      bc60 0000 0004 0008 0000 0000 0000         .'............

Tunnel teardown is initiated when linuxlt sends a StopCCN message. Notice that the tunnel ID in the L2TP header (52379) is the ID assigned by linux. As required by the protocol, linuxlt also sends its value of the tunnel ID (48224) as an AVP, making it unambiguous as to which tunnel is being torn down.

The result code AVP (Figure 4.38) is shown in boldface on lines 18.4 and 18.5. It shows a result/error code (Figure 4.39 and Figure 4.40) of 1/0 (general request to clear control connection/no error) and the optional human-readable message (Goodbye!).

The tunnel teardown is complete when linux responds with a ZLB, acknowledging that it received the StopCCN message.

The Control Connection

The control connection is a reliable connection that largely duplicates the semantics of TCP reliability. As we've seen, each control connection has sequence number and ACK fields that help provide reliability in the same manner that the corresponding TCP fields do. Once a message is sent, a retransmission timer is started. If the message is not acknowledged by the other side before the timer expires, the message is retransmitted, and the timer is restarted with a larger timeout value. After several unsuccessful attempts, the tunnel is considered down and is abandoned.

If the receiver of a control message has a response, it can acknowledge the control message in its response. If no response is necessary, the peer will respond with a common message header that contains no AVPs. This is the ZLB message. Its sole purpose is to acknowledge a previous message by indicating the next expected sequence number in its Nr field.

Like TCP, the control channel guarantees that control messages will be delivered in order and that it will make a sustained effort to deliver each message. When IP is used as the transport, the UDP checksum provides the same protection from corruption that TCP enjoys. Other transports have their own checksum schemes for protection against corruption. RFC 2661 recommends that TCP-like congestion control also be implemented for the control channel, but [Carlson 2000] reports that most implementations fail to do this.

If one of the tunnel endpoints has not received any messages from its peer for a certain amount of timeRFC 2661 recommends 60 secondsthe endpoint can send its peer a hello (HELLO) message. As we see from Figure 4.30, the HELLO is a control message, so after transmitting the HELLO, the sender can depend on the reliable-delivery mechanism of the control channel: either the HELLO will be delivered and acknowledged by the other side or will time out and cause the tunnel to be abandoned.

Because HELLO messages are global to the tunnel, the session ID field is 0. An unacknowledged HELLO will cause all sessions in the tunnel to be terminated. The HELLO mechanism allows both peers to discover independently that the tunnel is no longer functioning.

The HELLO message contains a single message type AVP, as shown in Figure 4.41.

Figure 4.41. HELLO AVP

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

Lines 12 and 13 of our sample session show an example of a HELLO sequence:

12   15:18:47.603327 172.30.0.4.l2f > 172.30.0.15.l2f:
      l2tp:[TLS](48224/0)Ns=2,Nr=5 *MSGTYPE(HELLO) (DF)
12.1    4500 0030 aa77 4000 4011 37f6 ac1e 0004    E..0.w@.@.7.....
12.2    ac1e 000f 06a5 06a5 001c 958f c802 0014    ................
12.3    bc60 0000 0002 0005 8008 0000 0000 0006    .'..............
13   15:18:47.609330 172.30.0.15.l2f > 172.30.0.4.l2f:
      l2tp:[TLS](52379/0)Ns=5,Nr=3 ZLB (DF)
13.1    4500 0028 1812 4000 4011 ca63 ac1e 000f    E..(..@.@..c....
13.2    ac1e 0004 06a5 06a5 0014 057a c802 000c    ...........z....
13.3    cc9b 0000 0005 0003                        ........

Incoming Calls from a Remote Host

When a remote host connects to a LAC, the LAC will initiate a session with the LNS. If a tunnel between the LAC and LNS does not already exist, the LAC will negotiate one before proceeding with the session establishment. The protocol that the LAC uses to establish a session is similar to the one used to establish the tunnel. As with tunnel establishment, there is a three-step handshake, as shown in Figure 4.42.

Figure 4.42. Incoming Session Establishment

After receiving a call indication from the remote hosteither from the remote host connecting to the LAC in mandatory mode or internally in voluntary modethe LAC sends an ICRQ to the LNS with information about the call. The LAC can defer answering the call (in mandatory mode) until the LNS agrees to establish the session, or it can immediately answer the call and perform LCP negotiation and authentication before sending the ICRQ. In either case, the LAC sends the ICRQ message to begin the session-establishment handshake.

The ICRQ has three required and six optional AVPs, as shown in Figure 4.43.

Figure 4.43. ICRQ AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

assigned session ID

14

8

1

•

call serial number

15

10

1

•

bearer type

18

10

1

called number

21

var

1

calling number

22

var

1

subaddress

23

var

1

physical channel ID

25

10

0

random vector

36

var

1

0

The assigned session ID AVP is this LAC's identification number for the session. The LNS will place this number in the session ID field of the common header. Because the LAC does not yet have the LNS's session ID, it puts a 0 in the session ID field of the ICRQ's common header.

The call serial number AVP is a 32-bit counter that identifies a particular call. This AVP is used by system administrators at the LAC and LNS for troubleshooting.

The bearer type AVP is similar to the bearer capabilities AVP; it consists of a 32-bit mask with the lowest-order bit indicating that the call is on a digital channel and the next-lowest-order bit indicating that the call is on an analog channel. In the case of a voluntary-mode connection, where the LAC is embedded in the remote host, both bits may be left unset.

The called number, calling number, and subaddress AVPs are variable-length ASCII strings that contain information about the phone numbers of the called and calling parties. The subaddress contains additional dialing information. RFC 2661 remarks that the LAC and LNS may have to agree on the interpretation of these fields.

The physical channel ID contains vendor-specific information about the physical channel of the call. This AVP is used only for logging purposes.

If the LNS agrees to accept the call, it will reply to the ICRQ with an Incoming-Call-Reply (ICRP). If the LNS does not want to accept the call, it will reply with a Call-Disconnect-Notify (CDN) message. We'll look at the CDN message shortly.

The ICRP has two required and one optional AVP, as shown in Figure 4.44.

Figure 4.44. ICRP AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

assigned session ID

14

8

1

•

random vector

36

var

1

0

We've already seen these AVPs in the ICRQ message.

After receiving the ICRP, the LAC answers the call, if it hasn't already done so, and then completes the session establishment by sending an Incoming-Call-Connected (ICCN) message to the LNS. The ICCN informs the LNS that the remote host is connected and passes the LNS some parameters concerning the physical-connection characteristics. If the LAC has already performed the LCP and authentication phases of PPP, the ICCN message will also contain information about the PPP parameters negotiated and the results of the authentication.

The ICCN message has 3 required and 12 optional AVPs, as shown in Figure 4.45.

Figure 4.45. ICCN AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

framing type

19

10

1

•

Tx connect speed

24

10

1

•

initial received LCP CONFREQ

26

var

0

last sent LCP CONFREQ

27

var

0

last received LCP CONFREQ

28

var

0

proxy authen. type

29

8

0

proxy authen. name

30

var

0

proxy authen. challenge

31

var

0

proxy authen. ID

32

8

0

proxy authen. response

33

var

0

random vector

36

var

1

0

private group ID

37

var

0

Rx connect speed

38

10

0

sequencing required

39

6

1

0

The framing type AVP is a 32-bit mask that describes the type of framing the LAC is using. If the lowest-order bit is set, the connection is using synchronous framing. If the next-lowest-order bit is set, the connection is using asynchronous framing.

The Tx connect speed AVP is a 4-byte value indicating the transmit speedfrom LAC to remote hostin bits per second. Similarly, the Rx connect speed is the speed of the connection from the remote host to the LAC. When the Rx connect speed AVP is missing, the receive speed is assumed to be the same as the transmit speed.

If the LAC performs PPP LCP negotiation with the remote host, the initial received LCP CONFREQ, last received LCP CONFREQ, and last sent LCP CONFREQ AVPs help the LNS to understand what PPP parameters the remote host requested and what values the LAC and remote host finally agreed on. The LNS uses these values to set the corresponding parameters in its PPP implementation just as if it had negotiated them itself.

If the LAC performs authentication of the remote host for the LNS, the proxy authen. type, proxy authen. name, proxy authen. challenge, proxy authen. ID, and proxy authen. response may be present. The proxy authen. type indicates the type of authentication that the LAC and remote host performed. The authentication types are shown in Figure 4.46.

Figure 4.46. L2TP Proxy Authentication Type

Type

Authentication Method

0

reserved

1

textual username/password exchange

2

PPP CHAP

3

PPP PAP

4

no authentication

5

Microsoft CHAP

If the LAC performs proxy authentication, the proxy authen. type AVP must be present. The other parameters may or may not be present, depending on the authentication method the LAC and remote host used.

The private group AVP indicates that the LNS should treat this call as belonging to a particular customer group. The attribute value field is an arbitrary sequence of bytes.

The sequencing required AVP indicates that sequence numbers must be used on data messages for this call. Recall that the LAC and LNS can use these sequence numbers to detect dropped or out-of-order messages.

We see these messages in action in lines 57 of our sample session:

5   15:18:08.255780 172.30.0.15.l2f > 172.30.0.4.l2f:
     l2tp:[TLS](52379/0)Ns=2,Nr=1 *MSGTYPE(ICRQ)
     *ASSND_SESS_ID(40607) *CALL_SER_NUM(3) *BEARER_TYPE() (DF)
5.1    4500 004c 17fd 4000 4011 ca54 ac1e 000f    E..L..@.@..T....
5.2    ac1e 0004 06a5 06a5 0038 6611 c802 0030    .........8f....0
5.3    cc9b 0000 0002 0001 8008 0000 0000 000a    ................
5.4    8008 0000 000e 9e9f 800a 0000 000f 0000    ................
5.5    0003 800a 0000 0012 0000 0000              ............
6   15:18:08.259860 172.30.0.4.l2f > 172.30.0.15.l2f:
     l2tp:[TLS](48224/40607)Ns=1,Nr=3 *MSGTYPE(ICRP)
     *RANDOM_VECTOR(4890def0d66a88ed4db0473642debca1)
     *ASSND_SESS_ID(20575) (DF)
6.1    4500 004e aa62 4000 4011 37ed ac1e 0004    E..N.b@.@.7.....
6.2    ac1e 000f 06a5 06a5 003a 8aa3 c802 0032    .........:.....2
6.3    bc60 9e9f 0001 0003 8008 0000 0000 000b    .'..............
6.4    8016 0000 0024 4890 def0 d66a 88ed 4db0    .....$H....j..M.
6.5    4736 42de bca1 8008 0000 000e 505f         G6B.........P_
7   15:18:08.260005 172.30.0.15.l2f > 172.30.0.4.l2f:
     l2tp:[TLS](52379/20575)Ns=3,Nr=2 *MSGTYPE(ICCN)
     *TX_CONN_SPEED(10000000) *FRAMING_TYPE(S)
     *RX_CONN_SPEED(10000000) (DF)
7.1    4500 004e 17fe 4000 4011 ca51 ac1e 000f    E..N..@.@..Q....
7.2    ac1e 0004 06a5 06a5 003a 85f4 c802 0032    .........:.....2
7.3    cc9b 505f 0003 0002 8008 0000 0000 000c    ..P_............
7.4    800a 0000 0018 0098 9680 800a 0000 0013    ................
7.5    0000 0001 800a 0000 0026 0098 9680         .........&....

On line 5, linuxlt initiates a session by sending linux an ICRQ message. As expected, the session ID field in the header is 0 because linux has not yet assigned an ID for this session. We see, however, that linuxlt has assigned session ID 40607.

In line 6, linux responds with the ICRP message as expected. This time, the header's session ID field is filled in with the value that linuxlt sent in its ICRQ message. Just as with the tunnel ID, the sender places its peer's session ID in the header.

The session is established when linuxlt sends the ICCN message. At this point, PPP can begin its negotiation. We can see this starting in line 8 of the sample session:

8   15:18:08.266317 172.30.0.15.l2f > 172.30.0.4.l2f:
     l2tp:[](52379/20575) {Conf-Req(1), ACCM=00000000,
     Magic-Num=c49a6f1e, PFC, ACFC} (DF)
8.1    4500 003a 17ff 4000 4011 ca64 ac1e 000f    E..:..@.@..d....
8.2    ac1e 0004 06a5 06a5 0026 7307 0002 cc9b    .........&s.....
8.3    505f ff03 c021 0101 0014 0206 0000 0000    P_...!..........
8.4    0506 c49a 6f1e 0702 0802                   ....o.....

As always, the L2TP message is encapsulated in a UDP datagram. The L2TP header, shown in boldface, has no flags set, so no optional fields are present (see Figure 4.26). After the header, we see the PPP packet starting with the address field. This is expected, as we are using synchronous framing as indicated in line 7.

Once the session is established and PPP negotiation is finished, we can send data over the session connection. Here is the result of a single ping and reply:

14   15:19:07.189282 172.30.0.15.l2f > 172.30.0.4.l2f:
      l2tp:[](52379/20575) {192.168 .122.2 > 192.168.122.1:
      icmp: echo request (DF)} (DF)
14.1    4500 0077 1815 4000 4011 ca11 ac1e 000f    E..w..@.@.......
14.2    ac1e 0004 06a5 06a5 0063 5b91 0002 cc9b    .........c[.....
14.3    505f 2145 0000 5418 1440 0040 01ad 40c0    P_!E..T..@.@..@.
14.4    a87a 02c0 a87a 0108 0085 b8b6 0b00 013b    .z...z.........;
14.5    16c1 3fd2 e102 0008 090a 0b0c 0d0e 0f10    ..?.............
14.6    1112 1314 1516 1718 191a 1b1c 1d1e 1f20    ................
14.7    2122 2324 2526 2728 292a 2b2c 2d2e 2f30    !"#$%&'()*+,-./0
14.8    3132 3334 3536 37                          1234567
15   15:19:07.193070 172.30.0.4.l2f > 172.30.0.15.l2f:
      l2tp:[L](48224/40607) {192.16 8.122.1 > 192.168.122.2:
      icmp: echo reply} (DF)
15.1    4500 0079 aa7a 4000 4011 37aa ac1e 0004    E..y.z@.@.7.....
15.2    ac1e 000f 06a5 06a5 0065 dd2a 4002 005d    .........e.*@..]
15.3    bc60 9e9f 2145 0000 54aa 7900 0040 015a    .'..!E..T.y..@.Z
15.4    dbc0 a87a 01c0 a87a 0200 008d b8b6 0b00    ...z...z........
15.5    013b 16c1 3fd2 e102 0008 090a 0b0c 0d0e    .;..?...........
15.6    0f10 1112 1314 1516 1718 191a 1b1c 1d1e    ................
15.7    1f20 2122 2324 2526 2728 292a 2b2c 2d2e    ..!"#$%&'()*+,-.
15.8    2f30 3132 3334 3536 37                     /01234567

The data portion of the hex dump does not appear to make sense, because PPP negotiated payload compression.

We deleted the lines containing this negotiation from our sample session.

When the peers are finished with the data session, they can release its resources by tearing the connection down. In our sample session, linuxlt initiates the teardown by sending a CDN message, and linux ACKs the message with a ZLB, as shown on lines 16 and 17:

16   15:19:55.713922 172.30.0.15.l2f > 172.30.0.4.l2f:
      l2tp:[TLS](52379/20575)Ns=6,Nr=4 *MSGTYPE(CDN)
      *RESULT_CODE(1/0 Bad file descriptor)
      *ASSND_SESS_ID(40607) (DF)
16.1    4500 0055 184f 4000 4011 c9f9 ac1e 000f    E..U.O@.@.......
16.2    ac1e 0004 06a5 06a5 0041 4bc2 c802 0039    .........AK....9
16.3    cc9b 505f 0006 0004 8008 0000 0000 000e    ..P_............
16.4    801d 0000 0001 0001 0000 4261 6420 6669    ..........Bad.fi
16.5    6c65 2064 6573 6372 6970 746f 7280 0800    le.descriptor...
16.6    0000 0e9e 9f                               .....
17   15:19:55.717628 172.30.0.4.l2f > 172.30.0.15.l2f:
      l2tp:[TLS](48224/40607)Ns=4,Nr=7 ZLB (DF)
17.1    4500 0028 aab4 4000 4011 37c1 ac1e 0004    E..(..@.@.7.....
17.2    ac1e 000f 06a5 06a5 0014 7712 c802 000c    ..........w.....
17.3    bc60 9e9f 0004 0007 0000 0000 0000         .'............

Outgoing Calls to a Remote Host

Just as the remote host can initiate a call through the LAC to the LNS, the LNS can initiate a call through the LAC to the remote host. As with incoming call requests, the call is established with a three-step handshake, as shown in Figure 4.47.

Figure 4.47. Outgoing Session Establishment

The first step in establishing an outgoing call is for the LNS to send an Outgoing-Call-Request (OCRQ) to the LAC. As we see from Figure 4.48, we have already encountered most of the AVPs in this message.

Figure 4.48. OCRQ AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

assigned session ID

14

8

1

•

call serial number

15

10

1

•

minimum bps

16

10

1

•

maximum bps

17

10

1

•

bearer type

18

10

1

•

framing type

19

10

1

•

called number

21

var

1

•

subaddress

23

var

1

random vector

36

var

1

0

The minimum bps and maximum bps AVPs specify the minimum and maximum speed in bits per second required for the outgoing call. Both attribute value fields are 32-bit integers.

If the LAC is able to honor the call request, it responds with an Outgoing-Call-Reply (OCRP) informing the LNS of the session ID and physical channel, as shown in Figure 4.49.

Figure 4.49. OCRP AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

assigned session ID

14

8

1

•

physical channel ID

25

10

0

random vector

36

var

1

0

After it has connected to the remote host, the LAC sends the LNS an Outgoing-Call-Connected (OCCN) message that notifies the LNS that the session is ready to proceed and informs it of the connection parameters. The OCCN has three required and three optional AVPs, as shown in Figure 4.50.

Figure 4.50. OCCN AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

framing type

19

10

1

•

Tx connect speed

24

10

1

•

random vector

36

var

1

0

Rx connect speed

38

10

0

sequencing required

39

6

1

0

If the LAC can't complete the call, it will send a Call-Disconnect-Notify (CDN) message to the LNS. Similarly, if the remote host disconnects or otherwise terminates the session, the LAC will send a CDN to the LNS. The LNS can also terminate the session by sending a CDN to the LAC.

The CDN has three required and two optional AVPs, as shown in Figure 4.51.

Figure 4.51. CDN AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

result code

1

var

1

0

•

Q.931 cause code

12

var

1

0

assigned session ID

14

8

1

•

random vector

36

var

1

0

Except for the Q.931 cause code, we've seen all these AVPs before. The Q.931 cause code is used to report the cause of an unsolicited Integrated Services Digital Network (ISDN) disconnection. Details about the format of this AVP are in RFC 2661.

Other Control Messages

There are two other control messages that we haven't yet explored. The first is the WAN-Error-Notify (WEN) message, used by the LAC to report WAN errors to the LNS. RFC 2661 specifies that this message be sent only when an error occurs and not more than once every 60 seconds.

The WEN message has two required and one optional AVP, as shown in Figure 4.52. The attribute value field of the call errors AVP consists of six cumulative counters for various types of errors, as shown in Figure 4.53.

Figure 4.52. WEN AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

call errors

34

32

1

•

random vector

36

var

1

0

Figure 4.53. Call Errors Attribute Value Field

[View full size image]

Our final control message is the Set-Link-Info (SLI) message. RFC 2661 describes the SLI message as a mechanism for the LNS to inform the LAC of negotiated PPP parameters, but its only use is for the LNS to inform the LAC of the asynchronous control character map (ACCM). Recall from Chapter 2 that each PPP peer can negotiate which bytes it requires its peer to escape. When it performs LCP negotiation, the LNS must inform the LAC of the ACCM, as it is the LAC that will perform the escaping.

The SLI message has two required and one optional AVP, as shown in Figure 4.54.

Figure 4.54. SLI AVPs

AVP

Attribute Type

Length

M Bit

H Bit

Required

message type

0

8

1

0

•

ACCM

35

16

1

•

random vector

36

var

1

0

The attribute value field for the ACCM AVP comprises two 32-bit character masks and a reserved field, as shown in Figure 4.55.

Figure 4.55. ACCM Attribute Value Field

[View full size image]

The L2TP specification is given in RFC 2661 [Townsley, Valencia et al. 1999]. [Shea 2000] gives an excellent and thorough exposition of the operation of L2TP. This is the place to look for an explanation of the various state machines and other internal L2TP mechanisms.

L2TP Futures

At the time of this writing, the IETF L2TP Extensions Working Group (see <http://www.ietf.org/html.charters/l2tpext-charter.html>) is developing the specifications for the next version (L2TPv3) of L2TP. Whereas L2TP is designed to carry PPP packets over various media, L2TPv3 generalizes this facility to the notion of a pseudowire that can transport many types of interface-layer packets, such as PPP, Ethernet, frame relay, and ATM.

In the context of the TCP/IP, L2TPv3 will provide the pseudowire by tunneling the link-layer protocols over either UDP, as L2TP does, or directly over IP. Although tunneling over IP seems cleaner and imposes less overhead, there are advantages to using UDP. Tunneling directly over IP does not interoperate well with NAT or, more precisely, PAT, because no port numbers are available for NAT to remap. Thus, tunneling L2TPv3 packets over UDP can help with NAT traversal.

In addition to separating the PPP functionality from L2TP proper and adding the capability to tunnel interface-layer protocols other than PPP, L2TPv3 adds additional AVPs and enhances some of the data structures. For example, the session and tunnel ID fields are 32 bits in L2TPv3.

Finally, L2TPv3 optionally extends the CHAP-like tunnel authentication mechanism to cover all packets in the control channel. To enable authentication, the peers exchange nonces during the tunnel establishment protocol.

A nonce is a number that is used only once. Typically, nonces are random numbers, but in some applications, counters or timestamps can be used as nonces. There is an excellent discussion of the various types of nonces and their uses in [Kaufman, Perlman, and Speciner 2002].

Each control message is authenticated by taking a cryptographic hashcurrently, HMAC-MD5 and HMAC-SHA-1 are definedof the concatenation of the two nonces, a shared key, and the message. That is,

D = H(LN || RN || K || m)

where D is the authentication digest, H is the hash function, LN is the local nonce, RN is the remote nonce, K is the shared key, and m is the message. The authentication digest is carried in an AVP attached to the message.

As we saw in Chapter 3, these digests assure both sides that the message is from its peer and has not been altered. The addition of the two nonces ensures that the message is from this incarnation of the tunnel and prevents replay attacks using packets from previous tunnels.


Section 4.7. MPLS

4.7. MPLS

Multiprotocol Label Switching (MPLS) is a way of tunneling IP datagrams, usually within and among autonomous systems.

Actually, MPLS can be used to tunnel any type of network-layer packetthus, multiprotocol. Because we are concerned mostly with tunnels in the Internet, we concentrate on MPLS's use with IP.

The idea is that a small label is inserted between the interface- and network-layer protocol headers, as shown in Figure 4.56, by the router at the entrance to the tunnel. Downstream routers use the label to make routing decisions, and do not need to consult the network-layer header at all. Thus, like all tunnels, MPLS treats the encapsulated IP datagram as opaque data and does not access it in any way while it's in the tunnel.

Figure 4.56. MPLS Label Encapsulation

[View full size image]

According to the MPLS Resource Center's FAQ (frequently asked questions) at <http://www.mplsrc.com/faq1.shtml>, MPLS was originally envisioned as a way to perform network-layer routing at the interface layerthat is, at ATM or frame relayspeeds. MPLS is now perceived as a means of providing traffic engineering, including quality of service; ATM-like virtual circuits at the network layer; interface-layer tunnels, such as Ethernet over IP/MPLS; a special type of VPN for enterprises that provides security comparable to that obtained with frame relay or ATM circuits; and a generally simplified network architecture where, for example, many ATM control plane functions are migrated to the network layer.

After looking briefly at how MPLS tunnels work, we then see how they can be used to provide a type of VPN. Because MPLS is usually implemented at the network service providerthat is, the autonomous systemlevel, most of us will not come into direct contact with it, but it does provide an interesting example of tunneling and is well worth our study.

The MPLS Architecture

As we've seen, routing in the Internet is a distributed process. Each router makes an individual decision as to the next hop for an IP datagram, based on network topology information learned from its neighboring routers. Except for the immediately preceding and next hops, routers don't usually know where a packet has been or the path it will follow to its destination. This is a powerful architecture because it is very resilient to changes in the network. If a downstream router fails after a packet has started its journey, the network is usually able to route around the failure by finding an alternative path for the packet.

The Internet routing model has shortcomings, however. As line speeds increase into the 10 and 100 gigabit per second range, it becomes more and more difficult for routers to make the forwarding decisions quickly enough to keep the links running at capacity. One of the difficulties is the time it takes to examine the IP header at each hop.

Another problem is traffic engineering and quality of service (QoS). Service providers might want to use different paths for different types of traffic. As a trivial example, interactive traffic, such as a telnet or ssh session, would be better routed over low-delay links, whereas ftp or Web page downloads might be better routed over high-speed links even if the average delay is greater. A more complex consideration is QoS: A provider might decide to sell specialized service at a premium. For example, a provider might guarantee a customer a minimum or average dedicated bandwidth through its network at a cost depending on the bandwidth the customer requires.

To deliver these types of services, network providers must segregate the IP traffic into distinct classes and treat those classes differently. This exacerbates the problem of examining the IP headers quickly enough to make forwarding decisions at high line speeds, of course, but it also requires information, such as customer identification, that intermediate routers won't have.

MPLS addresses these problems by assigning each IP datagram to a forwarding equivalence class (FEC). Class membership can be based on a simple criterion, such as destination network, or a more complex set of criteria involving service-level contracts with a customer, destination, protocol, TCP or UDP port numbers, time of day, and other policy constraints. Each packet in a FEC will follow a predetermined path, called a label switched path (LSP) through a series of MPLS-aware routers. An MPLS-aware router is called a label switching router (LSR).

The assignment of an IP datagram to a FEC takes place at the ingress routerthe first LSR in the path that the packet will follow. Subsequent LSRs in the LSP do not need to reclassify the packet; they merely forward it based on the label, as described next.

Routing with MPLS

A packet is assigned to a particular FEC by the ingress router. Each router has a label associated with each FEC it handles, but these labels are not unique among routers. That is, each LSR will have its own label for a given FEC. This label is purely a local matter except that a router's immediate upstream neighborsrouters that deliver packets directly to the LSR in questionwill also know it.

Before describing the routing process, we need one more fact: Packets can carry multiple labels arranged in a stack. Only the label at the top of the stack is used to route the packet. Other labels play no part until the top label is removed (popped) by one of the routers. We'll see how this mechanism is used later, when we discuss MPLS tunnels and VPNs.

The label is shown in Figure 4.57. The label comprises a 20-bit label value, an 8-bit TTL that's used to prevent routing loops, just as the TTL value in IP datagrams is, an S bit that, when set, indicates the bottom of the stack, and a 3-bit experimental field.

Figure 4.57. The MPLS Label

[View full size image]

The Exp field will probably be used to provide differentiated services for MPLS. RFC 3270 [Faucheur, Wu, Davie, Davari, Vaananen et al. 2002] discusses this in detail.

The encoding of the label and its use in routing is discussed in RFC 3032 [Rosen, Tappan, Fedorkow, Rekhter et al. 2001]. The use and processing of the label's TTL field is discussed in RFC 3443 [Agarwal and Akyol 2003].

When a packet arrives at an LSR, the router retrieves the label and uses it as an index into a local database.

An entry in the database is called a next hop label forwarding entry (NHLFE). As indicated in the diagram, labeled packets are mapped to one or more NHLFEs by using the label as an index into the incoming label map (ILM), which in turn points to the appropriate NHLFE or NHLFEs. Unlabeled packets are mapped to one or more NHLFEs by analyzing the packet to determine its FEC and then using the FEC and FEC-to-NHLFE (FTN) map.

Each entry of the database contains at least a next hop and a label-forwarding action. Possible label actions are:

  • Swap replace the label at the top of the stack with another label

  • Pop pop the label stack, removing the top label and exposing the next label, if any

  • Replace replace the label at the top of the stack with another label, and then push one or more additional labels onto the top of the stack

As an example of a typical routing event, let's suppose that LSR Ri receives a labeled packet. Ri first uses the label at the top of the stack to retrieve the appropriate entry in the label forwarding database. If we further suppose that the label action is to swap labels, Ri will replace the label with a new label specified by Ri+1, the router at the next hop. Ri then forwards the packet to the next hop indicated in the database entryRi+1 in this case. Note that Ri did not have to consult any network-layer headers to make this routing decision; the label determined both its actions and the next hop. These actions are repeated at each hop along the label switched path until the last router in the LSP is reached. The entire process is illustrated in Figure 4.58, where an IP datagram enters the LSP at ingress router LSR1 and is label switched through the LSP until it leaves the tunnel at router LSRn. While the datagram is in the MPLS tunnel, only the label is used for routing; the IP datagram itself is treated as opaque data.

Figure 4.58. An IP Datagram Traversing an LSP

[View full size image]

When the final router in the LSPthe egress routerreceives the packet, it pops the label from the stack. If there are further labels in the stack, the top label is used to make a routing decision as described in the label-swapping case; if the label stack is now empty and this is not the final destination for the packet, the router examines the network-layer header and makes its forwarding decision in the normal (non-MPLS) way.

Sometimes, the router just before the egress router will pop the label off the stack; this is called penultimate hop popping. This makes sense because the only use the egress router will make of the label is to notice that it should be popped. By having the previous router pop the label, the egress router is saved the label lookup overhead. This doesn't shift the cost of label processing to the previous router, because it has to perform one of the label actions in any case.

Label Distribution Protocols

In order for MPLS to operate, LSRs must inform their neighbors of the label/FEC bindings that they are using. That is, before router Ri can forward a packet belonging to FEC F to router Ri+1, it must know what label Ri+1 has assigned to F. The routers exchange label information by means of a label distribution protocol (LDP). Several label distribution protocols have been proposed, including, confusingly enough, one called LDP. Some of these protocols are extensions to existing protocols, such as BGP [Rekhter and Rosen 2001]; others, such as LDP [Andersson, Doolan, Feldman et al. 2001], are new protocols designed specifically for MPLS.

There are two methods for distributing labels: unsolicited downstream mode and downstream on demand mode. In unsolicited downstream mode, a router informs its immediate upstream neighbors of its label bindings without being asked. In this mode, the downstream router will send its neighbors label/FEC bindings when a label changes or when it first comes online.

In downstream on demand mode, the downstream router does not distribute label information unless it's asked. In this mode, the upstream router will request a label binding for a particular FEC whose packets it wants to forward to the downstream router as the next hop. A router can use either or both modes, depending on circumstances. The MPLS architecture document (RFC 3031 [Rosen, Viswanathan, and Callon 2001]) discusses these modes in detail.

If the upstream router has no use for a labelit doesn't use the downstream router as the next hop for the FEC that the label is bound toit may either discard it (conservative label retention mode) or keep it for possible later use (liberal retention mode). Generally, routers that have the necessary memory will use liberal retention mode because it saves requesting the label later if it's needed. Some routers, such as ATM-based LSRs, do not have the necessary memory and use conservative retention mode.

MPLS Tunnels

We have been discussing MPLS as another example of tunneling technology, but not all authorities treat MPLS this way. The exercises ask you to justify our treatment of MPLS in terms of tunneling by considering our definition of tunnels and verifying that it applies to MPLS. Aside from the question of whether MPLS itself is an example of tunneling, there is a notion of tunnels in MPLS. As we shall see, these MPLS tunnels certainly satisfy our definition of a tunnel.

To motivate the idea of this new type of tunnel, let's consider an example of their use from RFC 3031. Suppose that we have an autonomous system that functions purely as a transit AS. That is, it carries traffic for other autonomous systems, but traffic does not originate or terminate within the AS. Figure 4.59 shows this AS with four border routers B1, . . . , B4 and four internal routers I1, . . . , I4.

Figure 4.59. An MPLS Tunnel

[View full size image]

Let's suppose that border router B3 is advertising a route for network N and that an IP datagram with N as its destination enters the AS at router B1. As we saw in Chapter 2, the border routers will be running an exterior routing protocolBGP, sayand will be advertising to each other the external routes that they learn from their external BGP peers. The internal routers will be running an interior routing protocol, such as OSPF, and will learn the topology of the autonomous system's network from each other, and the external networks that they can reach from the border routers.

In the normal situation as described in Chapter 2, the internal routers will be aware of external as well as internal routing information. Thus, for example, I3 will know that any packets destined for network N should be sent to B3. This means that the forwarding tables of the internal routers must contain all the external routes, even though they will never originate traffic to any of those external networks.

Let's see how MPLS can solve this problem. First, it's clear that if the border routers were directly connected, there would be no problem: When the IP datagram destined to network N entered the AS at B1, the router would simply send it to its next hop, B3. Recall that one way of thinking about a tunnel is that it simulates a direct wire between two nodes. This suggests that we set up tunnels between the border routers.

If such tunnels were in place, the internal routers wouldn't need to know anything about external networks or routes. They would merely need to know how to carry tunneled traffic among the border routers; the actual traffic, including the fact that the payload is a packet destined for network N, would be opaque to them.

The MPLS label stack mechanism makes it easy to establish tunnels between two LSRs. For the rest of this example, let's assume that all the routers in the AS are LSRs. When it learns reachability information for network N from an external peer, router B3 assigns an MPLS label to the route and attaches it as a path attribute (see Chapter 2) to the rest of the routing information about N that it distributes to the other border routers. This process and the attribute formats are specified in RFC 3107 [Rekhter and Rosen 2001].

When B1 receives the IP datagram, it looks up the route for network N and discovers that the BGP next hop is router B3 and that B3 has assigned the label 3, say, to the route. Thus, B1 pushes the label 3 onto the MPLS label stack. Next, B1 again consults its routing table and learns that the next hop for router B3 is internal router I1 with a label of, say, 7. If we assume that the LSP between B1 and B3 is B1 [image] I1 [image] I4 [image] I3 [image] B3, we get the LSP and label stacks shown in Figure 4.59. I1 receives the packet from B1, swaps the label 7 at the top of the stack with a label of 4, and sends the packet to its next hop, I4. This process continues until the packet gets to I3, where the label action is to pop the label stackbecause of penultimate hop poppingand the next hop is B3. The packet travels from I3 to B3 with the single label of 3. B3 uses this label to look up the proper forwarding information for the packet and sends it on its way. B3 might pop the final label from the stack or it might swap it for another label if its neighboring AS is also using MPLS and the two autonomous systems have agreed to exchange labeling information.

Note how the internal routers don't need to carry any routing information about external networks; they are concerned only with routing packets within the AS. Also note how easy it is to apply traffic engineering or QoS with this topology. Suppose, for example, that the AS manager wants to give traffic from a certain external autonomous system priority. If we again assume that the traffic enters at B1 and is destined for network N, B1 can assign the packet to a different from normal FEC for the tunnel and thus assign it a different label. This other tunnel may take a differentfaster or better in some other waypath to B3. The only thing that changes from our example is that the labels at the top of the stack will be different. The bottom label will still be a 3, indicating to B3 that this packet is ultimately destined for network N.

MPLS VPNs

If we generalize the previous tunnel example slightly, we will see how MPLS can provide a special type of VPN that simulates a leased linea frame relay or ATM leased circuitthat has many of the isolation and security features that leased lines do. The idea is to isolate traffic among a customer's various sites by carrying it in MPLS tunnels and to keep routing information for a customer's sites completely separate from any other customer's routing data.

Let's assume that we have a service provider with two fictional customers: Acme Widgets and Ajax Gadgets. Acme has offices in New York, Dallas, and Los Angeles; Ajax has offices in New York, Chicago, and Dallas. Both Acme and Ajax wish to connect their various offices with private networks. The traditional way of doing this is with leased lines, but this can be very expensive. Instead, Acme and Ajax arrange to use their provider's MPLS network to obtain an equivalent, but cheaper, solution.

Our example assumes that only a single provider is involved, but two or more providers can cooperate in offering MPLS VPN services to their customers as long as they are all MPLS networks and are willing to share label information. For further information, see RFC 2547 [Rosen and Rekhter 1999], which discusses MPLS VPNs in detail.

As shown in Figure 4.60, each customer site accesses the provider's network with a customer edge (CE) router that connects to a provider edge (PE) router. The interior topology of the provider's network consists of provider (P) routers. P routers do not connect directly to customer routers.

Figure 4.60. MPLS VPNs

[View full size image]

The terminology we are using (CE, PE, and P routers) is from RFC 2547.

The PE routers act as border routers, and as we shall see, run BGP just as the border routers B1, . . . , B4 in Figure 4.59 did.

One of the nice features of MPLS VPNs is that customers may number their networks any way they like and may even use the same addresses as another of the provider's customers. For specificity, let's assume that Acme and Ajax have assigned their networks the addresses shown in Figure 4.61.

Figure 4.61. MPLS VPN Example Customer Site Addressing

New York

Dallas

Chicago

Los Angeles

Acme

10.1.0.0/16

10.2.0.0/16

10.3.0.0/16

Ajax

10.0.0.0/16

192.168.1.0/24

10.1.0.0/16

This example has some features that we should notice. First, the Acme New York site and the Ajax Chicago site have the same network address (10.1.0.0/16), so the provider's network will have to have some way of distinguishing them. Second, all the customers' sites are numbered with nonroutable addresses. Ordinarily, this would require NAT, but just as with our previous IP-in-IP example, the fact that the traffic to and from the sites will be tunneled makes this unnecessary. Finally, although Acme and Ajax do not share a common VPN is this example, it is possible that two or more customers that have a business relationship would require a secure way to exchange information. In that case, the MPLS VPN architecture allows a VPN to be set up among some or all of the separate companies' sites.

In order to set up an intercompany VPN, none of the sites involved can have the same network address, of course. Sites that are not involved in the common VPN can still have the same address as a site in another company's intracompany VPN.

In order to understand how an MPLS VPN operates, let's focus on Acme. The goal is to make the three offices appear to be on a common network. The illusion is that customer edge routers CE1, CE3a, and CE4a are connected with a mesh of leased lines, as shown in Figure 4.62.

Figure 4.62. The MPLS VPN as Seen by Acme's Sites

[View full size image]

One significant aspect of Figure 4.62 is that the Acme network is completely isolated from any other network. Although the traffic in our example is neither encrypted nor authenticated, the isolation ensures that traffic cannot be intercepted and that outsiders cannot inject forged packets into the network. When leased lines are used, the difficulty in breaching the physical security of the provider's network is what provides the security. As we shall see, in the case of MPLS VPNs, it is the isolation of routing data that provides the security. Because attackers do not know how to route to the customer's sites, they cannot interfere with the customer's traffic.

This assumes the security of the MPLS routers, of course. See [Dreyfus 1997] for an example of what happens when routers are compromised.

MPLS VPNs are implemented almost entirely in the provider edge routers. To see how this works, let's further narrow our focus to PE3, the New York provider edge router. PE3 is a routing peer with both Acme's CE3a and Ajax's CE3b customer edge routers, so in order to maintain isolation, PE3 has separate routing tables for Acme and Ajax.

In our simple example, this routing information consists of a single network, but the network topology behind a customer edge router could be arbitrarily complex, and a provider edge router could learn routing information for several networks from each of its customer edge routing peers. Similarly, a customer may have more than one VPN in service, which would generally result in separate routing tables for each VPN. For clarity, we are ignoring these possibilities in our example.

As we indicated earlier, the provider edge routers are BGP speakers that exchange routing and label information among themselves, just as in the MPLS tunnel example of Figure 4.59.

As PE3 learns routes from the customer edge routers, it advertises them to its BGP peers: PE1, PE2, and PE4. PE3 augments each route with a 64-bit route distinguisher that is used to distinguish routes from two customers with identically numbered networks. PE3 also adds a VPN target, or route target, that identifies the particular VPN that the route applies to. The VPN target enables PE3's BGP routing peers to assign the route to the correct routing table. PE3 will, of course, also assign a label to the route, just as in the case of MPLS tunnels.

Let us assume that PE3 assigns the label 18 for the route to the Acme 10.1.0.0/16 network. The "10.1.0.0" will be augmented to 96 bits by the route discriminator so that the other provider edge routers can distinguish it from the Ajax Chicago network of the same number. Finally, a VPN target will be assigned to the route to indicate that this route is for the Acme VPN. PE3 will advertise this information to the other provider edge routers in the usual BGP way. When the other provider edge routers receive this information, they will use the VPN target attribute to assign it to one of their routing tables.

Now suppose that the Dallas Acme office wants to send an IP datagram over the VPN to the New York office10.1.0.15, say. When the packet arrives from the Acme CE router, the Dallas PE router (PE4) looks up the route for 10.1.0.15 in the Acme routing table and determines that the BGP next hop is PE router PE3 and that this packet should be sent through the VPN associated with the label 18. The 18 is pushed onto the label stack, and the next hop for PE3a is determined from a global routing table. The label for this next hop is pushed onto the label stack, just as it was in the case of the MPLS tunnel example. The packet travels through the provider's network until it reaches PE router PE3, which pops the upper label if the previous router has not already done so and uses the label 18 to determine that the packet should be forwarded to CE3a, the Acme CE at New York. In most cases, PE3 can make the final routing decision based on the label alone and need not consult the IP datagram itself.

Just as with MPLS tunnels, the internal (P) routers need not know anything about the CE routers, the VPNs, or the routing information associated with them; they need merely know how to route traffic among the PE routers. This is an important advantage for service providers because it helps the network scale to a large number of VPNs. No single routerneither PE nor P routerneed be aware of all the routes used within the system. The P routers need know only the internal network topology, and a PE router need be aware only of the routing information used for VPNs that terminate at that PE router.

We have examined only the rudiments of MPLS VPNs. Many more complicated configurations are possible. For example, a company could have one or more VPNs that all its sites take part in and other VPNs that reach only some of its sites. Similarly, two or more companies can arrange to have intercompany VPNs. [Pepelnjak and Guichard 2001] covers all these and other configurations in detail.


Section 4.8. gtunnel

4.8. gtunnel

Sometimes, we want to build a type of tunnel that is not supported by the operating system, or we need to have finer control of the tunnel parameters than the operating system provides. In these cases, it is useful to be able to do our own encapsulation of packets as they leave the TCP/IP stack. In principle, we could do this by modifying the stack itself, but doing so has several disadvantages. First, it requires an intimate knowledge of the operating system's kernel, its data structures, and its support routines. More serious, unless the operating system's vendor can be persuaded to incorporate the changes into the base system, the modifications become a maintenance problem because they have to be reapplied with every new release of the operating system.

Fortunately, many operating systemsincluding FreeBSD, Linux, and Solarisprovide a facility that allows us to do the encapsulation easily in a user-space program. Our examples will use the FreeBSD tunnel driver, but Linux and Solaris offer essentially identical services through their TUN/TAP drivers. We refer to all these facilities as "tunnel drivers."

The tunnel drivers appear to the TCP/IP stack to be device drivers for a network interface device, such as an Ethernet card. Instead of encapsulating packets from the TCP/IP in, say, an Ethernet frame and passing the result to a physical device, the tunnel drivers deliver them to a user-space program, which performs further processing on the packet and then delivers it to the appropriate output device. Similarly, the user-space program can pass packets to the tunnel driver for delivery back up the TCP/IP stack.

A typical use of a tunnel driver is illustrated in Figure 4.63, which shows a user application talking to the TCP/IP stack in the normal way. The packets that result move down the stack to the tunnel driver, which delivers them to a user-space program, labeled gtunnel, that performs further processing and delivers them to the output device.

Figure 4.63. gtunnel and the Tunnel Driver

A typical use of the tunnel driver is illustrated by the FreeBSD PPP implementation. Rather than implement PPP in the kernel, as most other systems do, FreeBSD provides PPP functionality with a normal user-space application program called pppd. The pppd program communicates with the TCP/IP stack through the tunnel driver and with the outside world, typically, through a serial port. Thus, pppd encapsulates IP packets from the stack in PPP frames and delivers them to a serial port for transmission to the remote system. PPP frames from the remote system arrive at the serial port and are read by pppd, which strips off the PPP framing and delivers the resulting IP packet to the TCP/IP stack through the tunnel driver.

Building a gtunnel.c Skeleton

We can write our own programs that provide whatever processing and encapsulation are needed to implement a particular type of tunnel. To make this easier, we use the gtunnel.c skeleton shown in Figure 4.64. By providing the startup, inbound, and outbound functions, we can flesh gtunnel out to a complete tunnel implementation.

Figure 4.64. gtunnel Skeleton

[View full size image]

As we see from Figure 4.64, our skeleton provides merely the main function. We build a complete tunnel implementation by providing a startup function (line 12) to perform any necessary initialization and set up communications with our peer, as well as outbound (line 30) and inbound (line 32) functions to handle packets from the stack and our peer.

The main function

1 | We include the etcp.h header file, which contains prototypes for the error function, the definition for the INIT macro, and various other headers files needed for networking applications.
410 | These lines contain the read masks for the select call, the file descriptors for the input, output, and tun devices, and a working variable for return codes.
112 | The INIT macro sets the program name for use by the error function. After INIT, we call the startup function to perform any required initialization. We'll see an example of this function shortly. We pass the argc and argv variables to startup so that it can examine the program's command line parameters, and it returns file descriptors for the inbound and outbound functions. We might think that one file descriptor would suffice for both, but as we will see in Chapter 7, we sometimes want to talk to another process and therefore need a pair of pipes.
1315 | We open the tunnel driver. When we read from the driver, we are reading an IP packet from the stack. When we write to the driver, we are writing an IP packet to the stack.
1619 | Next, we perform the normal setup for the select call. We are interested in read events from the tunnel driver and our external peer.
20 | We enter the program's event loop on this line. We loop, waiting for input from the stack or our peer, process the input, and pass it on.
2228 | We ask select to notify us when input is available from either the tunnel driver or our peer. Any errors from select are noted, but we continue processing.
2930 | When we get input from the stack, we call outbound to read, process, and forward the packet to our peer.
3132 | When we get input from our peer, we call inbound to read, process, and forward the packet up the TCP/IP stack.

Building an IP-in-IP Tunnel with gtunnel

To illustrate the use of gtunnel, let's build an IP-in-IP tunnel like the one in Section 4.2, using the network configuration shown in Figure 4.65. The IP-in-IP tunnel will be built between the 192.168.1.1 interface on bsd and the 192.168.2.1 interface on laptop, with both interfaces assigned to the tunnel driver. The packets will actually follow the shaded path through the usual 172.30.0.0/24 network.

Figure 4.65. Network Diagram for an IP-in-IP Tunnel

We begin fleshing out gtunnel by including extra header files (Figure 4.66) that we will need and by adding a define and global definition to the start of gtunnel.c. We will call our new file ipip.c.

Figure 4.66. Header Files for ipip.c

[View full size image]

4

Our SOCKADDR define is simply a convenience macro to cast the sockaddr_in structures to the generic sockaddr structure expected by the BSD networking API.

5

We also define the global remote variable to hold the IP address of our peer.

In the startup function (Figure 4.67), we merely set our peer's IP address and allocate a socket for our communications with the peer. Our program will be invoked as

ipip peer_name_or_address

Figure 4.67. The startup Function

[View full size image]

The startup Function

1012

We begin by allocating a socket. Because we want our outer IP packets to have a protocol type of IP-in-IP (4), we set the socket type to SOCK_RAW and the protocol type to IPPROTO_IPIP.

1321

Next, we fill in remote with our peer's IP address. If the address is given as a numerical address, the inet_aton function will convert it to a 32-bit integer and store it in remote. Otherwise, we use gethostbyname to look up our peer's address.

22

Finally, we set both the file descriptors to the socket.
When the select call returns with a read event on the tun device, we call outbound (Figure 4.68) to process the packet.

Figure 4.68. The outbound Function

[View full size image]

The outbound Function

2830

We begin by reading the packet from the tunnel driver. Assuming that we're running on bsd, this will be an IP packet with a source address of 192.168.1.1 and a destination address of 192.168.2.1.

3134

We process this packet by simply sending it to our peer. As a result of the call to sendto, the TCP/IP stack will add an outer IP header with a source address of 172.30.0.1 and a destination address of 172.30.0.6, again assuming that we are running on bsd.

The inbound function (Figure 4.69) is only slightly more complicated. Because we specified SOCK_RAW for our socket, the packet will come to us with the outer IP header still in place. We must remove this header before sending the inner IP packet up the stack to the user application.

Figure 4.69. The inbound Function

[View full size image]

The inbound Function

4145

First, we read the packet from our peer as we normally would in any TCP/IP program. This packet will have the format shown in Figure 4.4.

4647

We strip off the outer IP header by first setting ip to point at the outer packet and then incrementing the pointer by the number of bytes in the outer header. After line 47, ip points to the inner IP header.

4951

We send the entire inner IP packet up the stack by writing it to the tun device. Notice that we get the size of the packet from the ip_len field of the IP header.

We can test our IP-in-IP tunnel by configuring the tun interfaces and starting ipip on bsd and laptop. For example, on bsd, we configure the tunnel interface using the normal ifconfig command and then start ipip:

bsd# ifconfig tun0 192.168.1.1 192.168.2.1 up
bsd# ./ipip laptop

In another window on bsd, we test our tunnel by pinging the remote interface:

[View full width]
$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64
   time=0.466 ms
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64
   time=1.464 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64
   time=0.454 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64
   time=0.523 ms
64 bytes from 192.168.2.1: icmp_seq=4 ttl=64
   time=0.405 ms
^C
--- 192.168.2.1 ping statistics ---
5 packets transmitted, 5 packets received, 0%
   packet loss
round-trip min/avg/max/stddev = 0.405/0.662/1.464
  /0.403 ms

If we examine the tcpdump capture of one of these pings, we see the expected encapsulation. Except for the addresses, it is identical to that from Section 4.2 (the outer IP header is set in boldface):

1   16:47:06.482086 172.30.0.1 > 172.30.0.6:
    192.168.1.1 > 192.168.2.1: icmp: echo request (ipip-proto-4)
1.1    4500 0068 17db 0000 4004 0a74 ac1e 0001    E..h....@..t....
1.2    ac1e 0006 4500 0054 17da 0000 4001 de7c    ....E..T....@..|
1.3    c0a8 0101 c0a8 0201 0800 b033 463e 0000    ...........3F>..
1.4    4aef 3041 945a 0700 0809 0a0b 0c0d 0e0f    J.0A.Z..........
1.5    1011 1213 1415 1617 1819 1a1b 1c1d 1e1f    ................
1.6    2021 2223 2425 2627 2829 2a2b 2c2d 2e2f    .!"#$%&'()*+,-./
1.7    3031 3233 3435 3637                        01234567

We've seen that by adding as little as 52 lines of code to our gtunnel skeleton, we can build a functional tunnel. Obviously, we could improve our tunnel by including code to track the tunnel health, to worry about MTUs, to provide diagnostics and other features, and so on (see Exercises 4.6 and 4.7, for example). The point is that gtunnel provides an infrastructure on which we can build arbitrarily complex tunnels.


Section 4.9. Summary

4.9. Summary

In this chapter, we've studied tunneling technology in depth. We began with a tentative definition of tunneling; after looking at an example, we refined it to be the encapsulation of a protocol's data in the payload of another protocol at the same or higher layer.

We looked at two common examples: IP-in-IP and PPPoE tunnels. We saw how they encapsulate the tunneled data and, in the case of PPPoE, how the tunnel endpoints can negotiate tunnel parameters.

Next, we looked at GRE tunnels as a way of decreasing the complexity of implementing tunnels. Instead of the X x Y implementations required to tunnel X protocols in Y protocols, GRE serves as a generalized mechanism allowing one protocol to be tunneled in another.

We examined the PPTP and L2TP protocols and observed how they serve as a generalization of the traditional telco-/modem-based RAS system. Although users think of PPTP and L2TP as VPN technologies, we examined only their tunnel aspects and left their security features for later investigation. We noted that PPTP, essentially a Microsoft product, is being replaced by L2TP. Both PPTP and L2TP depend on PPP to frame the tunneled packets.

We discussed MPLS, first as an efficient routing mechanism and then as a way of providing a kind of VPN. MPLS uses a small labelor stack of labelsprepended to packets in order to make efficient routing decisions. We observed that MPLS is useful mainly within an autonomous system but that it can be used across autonomous systems if their directors agree and coordinate labels.

Finally, we saw how we can use the gtunnel skeleton to build our own tunnels, whether or not they are supported natively by the operating system. We used gtunnel to build another version of the IP-in-IP tunnel.


Exercises

4.1 | Suppose that host A is multihomed, with one interface accessible to the Internet and the other interface on an enterprise's home network. Suppose further that host A is configured to forward IP packets from one interface to the other. In terms of a remote user wishing to access the home network, what advantages do PPTP and L2TP have over the remote user merely connecting to host A over the Internet using SSH, Telnet, or a similar protocol?
4.2 | Why does L2TP need a random vector when encrypting hidden AVPs?
4.3 | We said that MPLS tunnels IP datagrams or some other network-layer protocol. Explain how MPLS meets the definition of tunnel that we gave at the beginning of this chapter.
4.4 | How do the interface protocols, such as Ethernet, know that an MPLS label is present? This is obviously important, as an Ethernet, say, frame will be demultiplexed differently if an MPLS label is present.
4.5 | Use gtunnel to build a GRE tunnel between two hosts.
4.6 | Suppose that we have two gtunnel-based IP-in-IP tunnels to a host H. Our ipip program uses raw sockets, so each instance of the program will receive a copy of every IP datagram sent to either tunnel. Modify ipip to account for this.
4.7 | Add soft-state functionality, as discussed in Section 4.2, to the ipip program.


Part 2: Tunnels and VPNs

    Chapter 5. Virtual Private Networks

    Chapter 6. Secure Sockets Layer

    Chapter 7. SSH

    Chapter 8. Lightweight VPNs


Chapter 5. Virtual Private Networks

    Section 5.1. Introduction

    Section 5.2. PPTP

    Section 5.3. L2TP

    Section 5.4. Other VPNs

    Section 5.5. Summary

    Exercises


Section 5.1. Introduction

5.1. Introduction

In Part 2, we discuss virtual private networks (VPNs). Chapter 4 had some examples of VPNs, but we were interested mainly in their tunneling aspects and didn't dwell on their security and authentication features.

In this chapter, we define VPN and briefly revisit the VPNs from Chapter 4. In the rest of Part 2, we study several types of VPNs, see how they are used, and take note of their strengths and weaknesses. As we shall see, these VPNs can operate at any layer in the TCP/IP stack. As usual, we will be less concerned with the administrative details of configuring the VPNs than with developing an appreciation for the protocols themselves and the manifestation of those protocols on the wire.

Before beginning our discussion of VPNs, we should agree on a definition for them. We already have an implicit definition from our study of MPLS VPNs in Chapter 4. We might say that according to that definition, a VPN is a method of using tunneling to build a private overlay network on top of a public network in such a way that the security of the private network is equivalent to that provided by leased lines. But this definition suffers from a lack of precision as to the meaning of "security equivalent to that provided by leased lines" and is a bit too general for our purposes.

Instead, let us say that a virtual private network is an overlay network built with tunnels in which the tunnel payloads are encrypted and authenticated. Given that we use robust encryption and authentication, such a VPN would certainly provide security as good as or better than that provided by leased lines, so this definition is consistent, if more restrictive, than that for MPLS VPNs. The underlying notion of both definitions is that we are trying to create the illusion of a private network while using a public network, such as the Internet.

It's worth dwelling, for a moment, on the differences between a "real" private network and a virtual private network. As a first approximation, we could say that real private networks provide security by physical separation of the underlying communication media. Separate leased lines are dedicated to the network, and these leased lines carry traffic only for that network. This means that short of a physical wiretap, an attacker does not have access to network traffic.

As we saw in our study of MPLS VPNs, the security of real private networks does not necessarily depend on the actual separation of physical media. We can also achieve segregation of network traffic through routing, or by multiplexing several data channels onto a single physical cable.

MPLS VPNs are an example of providing a private network by using routing to ensure that a private network's traffic is delivered only to intended recipients. Because the assignment of the MPLS label, and thus the route, takes place within the MPLS cloud, an attacker on the edge of the MPLS network has no way to capture traffic from another private network or to inject packets into it.

In a typical transcontinental leased-line deployment, the customer is provided with a partial or whole T1 line. Even if the entire T1 line is dedicated to a single private network, the traffic from the user's T1 line is multiplexed onto a higher-bandwidth backbone, such as a T3 or OC4 line, for transport across the continent to the other endpoint's T1 line. Thus, traffic from the private network is carried on the same physical media as traffic from other networks. Nevertheless, from the point of view of a user of the private network, this data is inaccessible and as a practical matter does not exist.

Despite the realities of the previous paragraphs, our normal conceptual model for a leased-line connection is a dedicated wire from one site to another. This model includes the notion of a physical connection, and when we're told that the network is down, we imagine that a physical event, perhaps involving a backhoe, has taken place. A virtual private network, on the other hand, is just that: virtual.

As with a TCP connection, a VPN's tunnel is a purely notional construct consisting of shared state at the tunnel endpoints. When told that the VPN is down, our first thought is not that a cable has been cut but that the shared state has become desynchronized. Once one of the VPN's packets enters the Internet, it is like any other IP datagram in the Internet. A malefactor can use a flooding attack to cause a router to drop it or can inject phony packets into the VPN by forging some of the packet's header fields. To protect itself from these and other attacks, a VPN relies on encryption and authentication to secure its data.

The advantages of a VPN over an actual private network should be clear. Instead of expensive leased lines or other infrastructure, we can make use of the relatively inexpensive, high-bandwidth Internet. More important in many instances is the ubiquity of the Internet. In most developed areas, access to the Internet is readily available without special provisioning or long waiting times. Given a VPN with robust cryptographic primitives and protocols, we could argue that a VPN is, in fact, more secure than a dedicated leased line, even if we accept our conceptual model of such a line as real.

In our definition of VPN, we said that the tunnel payload is protected by encryption and authentication. As we study the various types of VPNs, we will see that the meaning of payload depends on the class of VPN. In Chapter 6, for example, we study SSL tunnels, which operate primarily at the application layer. Thus, the payloads that they encrypt and authenticate are usually application data. At the other end of the spectrum, tunnel-mode ESP in IPsec (Chapter 12) operates at the network layer, so its payloads are entire IP datagrams.


Section 5.2. PPTP

5.2. PPTP

We studied the tunneling aspects of PPTP in Chapter 4, where we viewed it as a type of remote access server that doesn't require expensive capital expenditures on modem banks and telco lines. As we mentioned, users view PPTP primarily as a VPN technologythey perceive its main benefit as secure communications. In this section, we take a brief look at PPTP's VPN properties.

If we reexamine the PPTP message types, we see that none of them deals with encryption or authentication. That's because PPTP really is a tunneling protocol, not a VPN protocol. PPTP relies on the underlying PPP protocol for its encryption and authentication services: In practice, that means Microsoft's Microsoft Point-to-Point Encryption (MPPE) [Pall and Zorn 2001] and Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) [Zorn and Cobb 1998].

At first glance, these seem like reasonable cryptographic protocols. MPPE uses RC4, which we saw and remarked on in Chapter 3. MS-CHAP is Microsoft's version of PPP CHAP, a typical challenge/response protocol. Unfortunately, Microsoft's implementation of these protocols has several problems.

The MS-CHAPv1 protocol has several weaknesses that make recovery of the user's password comparatively easy using a dictionary attack. MS-CHAPv2 fixes the worst of these weaknesses but is still susceptible to an attack where a dictionary of N trial passwords can be checked at a cost of about N/216 attempts and some precomputation.

The version of MPPE used with MS-CHAPv1 has a fatal flaw: It uses the same RC4 key for both the PAC and PNS, resulting in reuse of the key stream. As we saw in Chapter 3, this leads directly to the recovery of both plaintext streams. With MSCHAPv2, Microsoft changed MPPE to avoid the key stream reuse, but serious problems remain. The main problem is that the RC4 session keys are derived in a deterministic way from the user's password and information passed in the clear. Thus, the keys have the same entropy as the password instead of the 128 bits that a randomly generated session key would have. Because user passwords are generally low entropy and, with MSCHAP, susceptible to a particularly effective dictionary attack, PPTP cannot be considered to have robust encryption.

Finally, there is no per packet authentication. This means that various bit-flipping attacks are possible on the encrypted data.

We can "flip," or change, any bit without detection when using RC4 and similar stream ciphers. If we know that a certain bit in a message is important for some reason, we can easily change it. Suppose, for example, that we know that the most significant bit of byte X in a message enables certain features that make it more difficult for an attacker to compromise the security of the system. If we know that the bit is turned on, we can turn it off by merely exclusive-ORing 0x80 with byte X of the ciphertext. Note that we don't have to know the encryption key or even the plaintext value of byte X to do this: only that we want to change the most significant bit. It's easy to see how we can generalize this to alter larger units of data if we know their plaintext values and positions in the data stream.

The PPP control protocols, such as LCP, are particularly vulnerable, and it may be possible to convince the client and server to use the older MS-CHAPv1 protocol, resulting in fairly easy user password recovery and compromise of the RC4 cipher stream.

The fact that MS-CHAPv2 considerably strengthened the Microsoft version of PPTP notwithstanding, almost all experts recommend against using PPTP. The specifics of the MS-CHAP and MPPE weaknesses are detailed in [Schneier and Mudge 1998] and [Schneier, Mudge, and Wagner 1999].

The weaknesses we have been discussing are specific to the Microsoft implementation, of course, but this implementation is the preponderant one. Virtually all other PPTP implementations are written to interoperate with Microsoft's, so they are likely to share the same weaknesses.


Section 5.3. L2TP

5.3. L2TP

L2TP has minimal built-in security. The LAC and LNS can authenticate each other during tunnel setup, and most AVPs can be encrypted, but L2TP, like PPTP, depends on PPP to protect the user data in the tunnel. This default security has several problems.

Let's put aside the problems with MPPE and MS-CHAP for the moment and assume that we have robust versions of CHAP and an encryption protocol installed in our PPP implementation. Unfortunately, we are still far from secure. Let's take a look at some of the problems that remain.

First, the control channel, once set up, is unprotected except for any AVPs that are encrypted. This means that an attacker can easily disrupt the tunnel by, for example, sending a forged StopCCN message to the LAC or LNS. The attacker will have to know the tunnel ID and proper sequence numbers, of course, but they are easily obtained by snooping the tunnel or even by informed trial and error.

A parallel weakness exists in PPP. Although packets carrying user data are encrypted, control packets, such as LCP, CHAP, and IPCP packets, are not. This means that PPP can leak information, such as the internal IP addresses of the enterprise network. It also means that active attacks, such as sending a forged packet pointing to a compromised DNS server, are possible. Because PPP packets are not authenticatedwhether or not encryption is in usethese types of attacks are particularly easy.

This last point is an important one. Because neither PPP nor L2TP messages are authenticated, they are subject to various manipulations.

We must distinguish here between the endpoint authentication, which happens at L2TP tunnel setup and PPP session establishment, and message authentication. Endpoint authentication typically involves a CHAP-like mechanism to convince each side of the proposed connection that its peer is who he says he is. Message authentication, on the other hand, refers to providing each message with a message authentication code, such as one of the HMACs we discussed in Chapter 3, to guarantee that the message is from the peer, not a forged message injected into the message stream by an attacker, and that it has not been modified since the MAC was calculated. Message authentication is sometimes called message integrity to distinguish it from endpoint authentication. Similarly, MACs are sometimes called message integrity codes (MICs).

Those who are not well versed in security and cryptographic protocols often believe that encryption alone provides message authentication. After all, if the message is not from the peer, how did the attacker encrypt it? Similarly, how could an attacker alter a message's plaintext without knowing the encryption key? Unfortunately, even encrypted messages are subject to manipulation by an attacker. Data that is encrypted with a stream cipher is subject to bit-flipping attacks, as we noted in our discussion of PPTP. Data encrypted with block ciphers is subject to cut-and-paste attacks, as we'll see in Chapter 12. Thus, the lack of message authentication in L2TP is a serious security shortcoming.

As we mentioned in Chapter 4, the forthcoming L2TPv3 will provide optional authentication for all messages in the control channel.

A consequence of L2TP's lack of message authentication is that there is no replay protection. That is, an attacker can replay previous messages in order to confuse the protocol or end application. We would not, for example, want to allow a previous request for a bank fund transfer to be replayed. Replay attacks can easily be prevented by adding a sequence number to each message and then authenticating the message. Notice that the sequence number alone is insufficient, as the attacker could merely supply the expected sequence number of an unauthenticated message. It is the authentication that prevents such trivial attacks.

Another problem with L2TP and PPP encryption and endpoint authentication is that they are based on a single shared secret. There are two issues with this: First, this shared secret could be compromised in some manner outside of the protocol, and once compromised, all previous and future traffic can be read, and the enterprise network that it is protecting is subject to immediate attack. Second, the shared secret is long lived, allowing an attacker to accumulate a large amount of data encrypted with it. The more data that a cryptanalyst has, the easier it is to break the encryption and discover the key.

VPNs generally have more robust key-management protocols that change keys often and prevent the accumulation of data that a cryptanalyst can work with. MPPE does this to a limited extentthe session key can change with every packet or after 256 packetsbut because these keys are derived from a single shared secret and information sent in the clear, their security is no better than that of the shared secret. If the shared secret is compromised, all messagespast and futurecan be read.

The ideal key-management protocol has a property called perfect forward secrecy (PFS). This means that each session key is independent and that the compromise of one such key does not compromise any of the others. Thus, our complaint about MPPE in the previous paragraph is that although it does change keys frequently, thereby making brute-force attacks more difficult, it does not enjoy the PFS property. This is a problem with PPP in general; none of the encryption protocols defined for use with it enjoy PFS or have robust key-management protocols. Indeed, as of this writing, they all depend on a shared secret.

L2TP and IPsec

Because L2TP has such weak native security, many experts consider it a remote access technology rather than a VPN. On the other hand, users tend to think of it as a VPN technology and are interested primarily in protecting their communications. One way of reconciling these two views is to combine L2TP with an external security protocol. The most popular way of doing this is to run L2TP over IPsec (Part 3).

IPsec provides encryption, authentication, and other security services at the network layer. IPsec can run in several modes and provide differing security services, but for now, let us merely stipulate that IPsec can provide encryption and authentication for IP packets. In particular, we shall be interested in ESP transport mode (Chapter 12), in which the payload of IP datagrams is encrypted and authenticated while in transit between, in this case, the LAC and LNS. Figure 5.1 shows the encapsulation of the L2TP header and message within IPsec, UDP, and IP.

Figure 5.1. Encapsulation of L2TP Within IPsec

[View full size image]

With this encapsulation, the UDP header, the L2TP header, the L2TP message, and parts of the IPsec header and trailers are encrypted and authenticated, giving complete protection for everything in the L2TP tunnel. That is, the control channel and all the data channels, including the PPP control protocols, such as LCP and IPCP, are protected from snooping and alteration. This solves the problem that we have with plain L2TP of leaving these protocols unprotected. Finally, ESP provides replay protection, so L2TP/IPsec is also safe from replay attacks.

Given a connection over an L2TP/IPsec tunnel from a remote host to a host on the enterprise network, it is important to understand what parts of the path between the two hosts are protected. In the most common case of the road warrior with a voluntary connection to the enterprise network, we have the situation shown in Figure 5.2. If we assume that the remote host is communicating with one of the servers on the enterprise network, we almost have an end-to-end VPN. The L2TP/IPsec tunnel ends at the LNS on the enterprise network, so the final hop to the server is unprotected, but this won't matter for most applications, because the LNS and the server are both on the enterprise network, which is presumably protected by firewalls and other means from outside interference. Notice though, that the connection is still subject to snooping or manipulation by a host inside the enterprise. If this is a concern, another VPN could be established between the LNS and the server.

Figure 5.2. An L2TP/IPsec VPN Between a Road Warrior and the Enterprise Network

Another typical application of an L2TP/IPsec VPN is shown in Figure 5.3. Here, a remote network, such as a branch office, is connected to the enterprise network through an L2TP/IPsec tunnel. We assume that a host on the remote network has a connection to a server on the enterprise network.

Figure 5.3. An L2TP/IPsec VPN Between Networks

[View full size image]

The security situation at the enterprise network is exactly like that in Figure 5.2: The connection is unprotected from the LNS to the server. The situation at the remote network is a little more complicated. If we assume that the host is talking to the LAC over a PPP connection, we can arrange that the data between the host and LNS is encrypted by PPP. That means, of course, that the data is doubly encrypted over most of the path between the host and the server, but more important, there is limited protection for the conversation on the remote network. Thus, such a connection would be resistant to snooping by a host on the remote network.

Other configurations are possible, of course, so it is important to evaluate the security of each leg in any proposed L2TP/IPsec VPN topology. If we trust the hosts and servers on the private networks, we needn't be too concerned about the lack of security there. If we don't trust them, we must take steps to ensure that any sensitive data is protected from snooping or alteration from within the private networks.

Microsoft uses the combination of L2TP/IPsec as its VPN solution (replacing PPTP), so we can expect to see this topology frequently. Nonetheless, not everyone agrees that this is a good solution.

First, it reintroduces the NAT problem. Recall that L2TP uses UDP encapsulation rather than GRE, as PPTP does, and that the rationale for this was that it allowed L2TP to interoperate with NAT. When L2TP is combined with IPsec, the UDP header is encrypted and thus unavailable to NAT. This means that the most common NAT mode, PAT, cannot be used. Fortunately, this problem is being solved. The IETF is developing a standard for a technology, called NAT traversal (NAT-T), that allows IPsec to interoperate with NAT. The Microsoft implementation of L2TP/IPsec includes a version of NATT. We discuss NAT-T further in Chapter 14.

The other common complaint about L2TP/IPsec is that it's a solution in search of a problem. Critics complain that L2TP not only adds overhead and does not scale well, but also fails to solve any problems that IPsec alone can't solve. Microsoft and other L2TP adherents counter that L2TP enables the use of existing session authentication protocols, such as MS-CHAP, and makes use of PPP's ability to assign IP addresses and DNS servers to the remote host. [Messmer 2000] discusses the pros and cons of L2TP/IPsec deployment. Chapter 10 of [Shea 2000] has an excellent summary of L2TP security concerns and a discussion of L2TP/IPsec. RFC 3193 [Patel, Aboba, Dixon et al. 2001] discusses securing L2TP with IPsec in detail.


Section 5.4. Other VPNs

5.4. Other VPNs

In the remainder of Part 2, we examine several other VPN technologies. We begin with examinations of the SSL/TLS (Chapter 6) and SSH (Chapter 7) protocols. Because these protocols operate at the application layer, some might consider them merely secure applications and not real VPNs. We will see, however, that they meet our definition for a VPN, and that we can, in fact, use them to build traditional network-to-network VPNs.

Regardless of whether SSL/TLS and SSH are "real" VPNs, they solve the central problems of privacy, authentication, and key management that every VPN must address. By studying their solutions to these problems and by noting where they succeed and where they fail, we will gain a deeper appreciation for both the problems and their solutions. Indeed, we will see that the design sets we introduce in our examination of SSL/TLS and SSH are used again and again in other types of VPNs. For these reasons alone, our study of these protocols will pay handsome dividends.

Next, we introduce and study some lightweight VPN technologies. When we say that they are lightweight, we mean that they are simpler and easier to deploy than, for example, the more comprehensive IPsec protocols (Part 3). In some applicationsespecially ad hoc applicationsusing one of these protocols might make sense.

We begin with an examination of VTun, a very simple VPN that illustrates the difficulty of engineering robust security protocols. At the same time, VTun also illustrates the use of a common framework for building lightweight VPNs. Because of its simplicity, VTun exposes this framework in a way that makes it easy to see and understand.

After VTun, we take a quick look at CIPE, a VPN running only on Linux and Windows NT. Because CIPE depends on a kernel module, porting it to other platforms is difficult. As we'll see, CIPE solves some of the security problems in VTun but still has flaws.

Next, we examine tinc, a VPN using the same framework as VTun. We'll see that it solves most of the problems that CIPE did not resolve. Tinc is interesting because it is designed as a network of VPNs, where a set of tinc gateway nodes securely connect a series of networks by maintaining encrypted tunnels between the nodes. Within this network, tinc manages routing and the decryption and reencryption of IP datagrams as they pass through intermediate nodes to their destination node.

Finally, we study OpenVPN, an excellent VPN that appears to offer security comparable to that of IPsec. OpenVPN achieves this by reusing the TLS/SSL protocol (Chapter 6) for endpoint authentication and key exchange, and by closely mimicking ESP (Chapter 12) for its data channel. Although it uses the same simple framework as VTun and tinc, OpenVPN provides robust security by leveraging the proven SSL and ESP protocols.

Again, the study of these VPNs will deepen our appreciation for the problems that all VPNs must solve. It will also help us to understand their limitations and enable us to make informed decisions as to whether they are appropriate for any given application.


Section 5.5. Summary

5.5. Summary

In this chapter, we agreed on a definition of VPN and acknowledged that even with our definition, there can still be disagreement about whether a particular technology is a VPN or merely a secure application. We saw how this definition applies to PPTP and L2TP and examined the extent to which those protocols provide a robust VPN.

We ended the chapter by providing a road map for the rest of Part 2. We indicated that we will study SSL, SSH, and four lightweight VPNs.


Exercises

5.1 | Verify the statements concerning bit flipping in stream ciphers. Specifically, show that exclusive-ORing a 1-bit into the ciphertext changes the corresponding plaintext bit.
5.2 | Would it make sense to reverse the L2TP/IPsec encapsulation? That is, what would be the advantages and disadvantages of establishing an IPsec connection between a host on a remote network and a server on the enterprise network, and then running that through an L2TP tunnel between the LAC and LNS? The topology would be similar to that in Figure 5.3, but IPsec would be encapsulated in L2TP messages instead of the other way around.
5.3 | Make the argument that a VPN is more secure than a leased line.
5.4 | Given a VPN with robust cryptographic primitives and protocols, or a dedicated leased line, what are the most vulnerable points in the network? That is, if a malefactor were tasked with compromising the network's data, how should the attacker proceed?


Chapter 6. Secure Sockets Layer

    Section 6.1. Introduction

    Section 6.2. Cipher Suites

    Section 6.3. The SSL Protocol

    Section 6.4. SSL on the Wire

    Section 6.5. OpenSSL

    Section 6.6. The stunnel Program

    Section 6.7. SSL Security

    Section 6.8. Summary

    Exercises


Section 6.1. Introduction

6.1. Introduction

The most ubiquitous transport-layer tunneling protocol, by far, is the Secure Sockets Layer (SSL)the protocol used to, among other things, secure HTML (Hypertext Markup Language) transactions on the Web. As we shall see, SSL has many applications and can easily be used to build general-purpose transport-layer tunnels. In this chapter, we examine the SSL protocol, watch its operation on the wire by means of the tcpdump and ssldump utilities, see how we can use it to build a tunnel between two programsone or both of which need not be SSL-awareand, finally, see how we can use it to build a VPN between two networks.

The first SSL specification originated in 1994 at Netscape, which was interested in a way to secure certain transactions made with its Netscape Navigator Web browser. The first version was not released outside Netscape. Later that same year, the specification for version 2 of SSL (SSL 2) was released [Hickman 1995], and an implementation appeared in Netscape Navigator 1.1 early in 1995.

Unfortunately, the SSL 2 protocol had security problems, and the Netscape implementation, in particular, had serious security flaws due to the way the pseudorandom number generator was seeded.

The seeding method and the exploit that took advantage of it are described in [Goldberg and Wagner 1996]. Because the seed was calculated from the time of day, the UNIX process ID (pid), and parent's process ID (ppid), Goldberg and Wagner were able to significantly reduce the number of possible keys to try. An attacker who had an account on the same machine and thus knew the user's pid and ppid, could recover the key in about 25 seconds. According to [Rescorla 2001], even without direct access to the pid and ppid, Goldberg and Wagner were able to discover the key in about an hour.

At the same time, other vendors were producing their own implementations. One of these, Microsoft's Private Communications Technology (PCT), addressed several shortcomings of SSL 2, had better security, and was backward compatible with SSL 2.

In late 1995, Netscape released the version 3 (SSL 3) specification. SSL 3 was a complete rewrite of SSL, which included many of the features of PCT, added new cipher suites, and introduced a closure notification that prevented truncation attacks.

Before SSL 3, it was possible for an attacker to send a forged TCP FIN to one or both sides, making it appear that less data was transmitted than actually was. The closure notification prevents this by sending what amounts to an EOF as part of the (authenticated) protocol. We'll see the close notification in action shortly.

Most browsers and servers currently use SSL 3, although as we'll see, many browsers first try to negotiate an SSL 2 connection. The latest edition of the SSL 3 specification is [Freier, Karlton, and Kocker 1996].

This document was published as an Internet Draft but never became an RFC. Netscape continues to make it available as the best written specification of SSL 3.

We'll discuss the security properties of SSL 3 shortly.

In 1996, the IETF began an effort to standardize the SSL protocol. For political reasons, the new protocol was named the Transport Layer Security (TLS) protocol. TLS is based mostly on version 3 of SSL but with enough "minor" changes to make it incompatible with SSL 3. The TLS specification was finished in 1999 and published as RFC 2246 [Dierks and Allen 1999].

At the time of this writing, SSL 3 remains the dominant protocol. Deployment of TLS has been slow, but its use is increasing. We use SSL to stand for both TLS and the various versions of SSL. We use the specific names SSL 2, SSL 3, and TLS when it's necessary to distinguish which version we are speaking about.


Section 6.2. Cipher Suites

6.2. Cipher Suites

SSL makes use of three cryptographic functions. First, the two sides need a way of exchanging keying material with each other. Part of this key exchange can also provide authentication of the server.

Second, there must be a method of encrypting the application data and other secured messages in the protocol. SSL supports several ciphers, both stream and block, for this purpose.

Finally, each record transmitted must be authenticated. This is accomplished by adding a cryptographically secure message digestor HMAC, see Section 3.4to each record. Because one of the inputs to the HMAC will be a sequence number, replay attacks as well as data alterations can be detected.

SSL supports many different combinations of these three functions, so the peers need a way of specifying which particular set of functions they support and will use. A cipher suite is a triple consisting of the key-exchange method, a cipher, and an HMAC. Figure 6.1 lists the standard cipher suites.

Figure 6.1. Cipher Suites
[View Full Width]

The three suites using FORTEZZA_KEA are not supported by TLS and are virtually never used outside of government settings, as they require additional hardware.


Section 6.3. The SSL Protocol

6.3. The SSL Protocol

Many of the SSL messages and mechanisms deal with crypto export restrictions that no longer exist. Although now not required, these mechanisms continue to be supported in the name of backward compatibility. Because they all involve weakening the encryption in some way, they are of little interest to us, and we will not cover them. [Rescorla 2001] has a nice discussion of these mechanisms for those interested.

We begin by examining the exchange of packets in a typical SSL session. As a transport-layer protocol, SSL depends on a transport-layer protocol to carry its packets. In principle, there is no reason that SSL couldn't run over UDP, but reliability would have to be built into the SSL protocol itself. To avoid these complications, SSL requires a reliable transport protocol to run over. In practice, this means TCP.

In response to the need for a general protocol that protects UDP traffic, Rescorla and Modadugu have proposed the Datagram Transport Layer Security (DTLS) protocol. DTLS provides a retransmission timer for the SSL handshake but otherwise does not attempt to add reliability to the underlying transport. In particular, DTLS is insensitive to lost or reordered data messages. DTLS offers optional replay protection using the same method that IPsec implements in AH (Chapter 11) and ESP (Chapter 12).

In early 2005, the DTLS proposal was still at the Internet Draft stage. The latest draft of the proposal is available from the Transport Layer Security Working Group's Web site at <http://www.ietf.org/html.charters/tls-charter.html>.

As with TCP, we can think of an SSL session as having three stages: connection setup, data transfer, and connection teardown. In the first stage, the encryption, authentication, and compression algorithms are negotiated; the identity of the server and, optionally, the client is verified, and a key exchange takes place.

In the second stage, the client and server exchange application data. These exchanges are encrypted and authenticated to ensure that the data cannot be read by third parties (encryption) and that third parties cannot alter the data without detection (authentication).

When the applications have finished exchanging data, one or both of them send a closure notification as an EOF. Because the closure notification is authenticated, it can't be forged by a third party. This prevents malevolent parties from forging a TCP FIN and truncating the data prematurely.

The SSL 3 and TLS specifications require that both sides send closure notifications, but in practice, this is often ignored, and only one side sends it.

Basic SSL Packet Flow

Figure 6.2 shows a typical SSL session. The first nine messages comprise connection establishment. In this phase, the client sends the server a ClientHello message that specifies which version of SSL it supports and lists the cipher suites and compression algorithms that it is willing to use.

Figure 6.2. Basic SSL Packet Flow

The server responds with three messages.

As we'll see later, the peers generally coalesce the messages in each step of the handshake, so these three messages will be sent as a single TCP segment.

The first, the ServerHello message, informs the client which cipher suite and compression algorithm the server has chosen.

The second message is the server's certificate. The certificate serves two purposes. First, it allows the client to verify the identity of the server. Second, it contains the server's public key, which the client uses to encrypt a secret that will be used by both sides to generate the cryptographic keys needed for the session.

Finally, the server sends a ServerHelloDone message. Because some SSL modes require additional server handshake messages, the ServerHelloDone packet serves to mark the end of the server's hello sequence. At this point, the server has positively identified itself to the client, the client and server have agreed on cipher suites and compression algorithms, and the client has the necessary key to securely send the server some key-generating material.

In the next three messages, the client sends the server some key-generating material (ClientKeyExchange), tells the server that it will henceforth use the newly generated keys to encrypt and authenticate its messages (ChangeCipherSpec), and informs the server that it has completed its part of the handshake (Finished). The server responds with its own ChangeCipherSpec and Finished messages.

Now the applications are ready for the data exchange phase. The data transfer looks like any other TCP data transfer except that the data in the TCP segments is encrypted and authenticated. When we watch this transfer with tcpdump, we'll see that it is indistinguishable from any other TCP data transfer except that the application data appears to be random bits.

The last messages are the closure notifications. At this point, data can no longer be transmitted, and the connection is shut down.

The SSL Record Layer

Before taking a detailed look at SSL in action, we need to understand the SSL record layer. All SSL messages are carried in SSL records that identify what type of messages are in the records, the length of the messages, and the version of SSL being used. Figure 6.3 shows the general format of these records.

Figure 6.3. The SSL Record Format

[View full size image]

The 8-bit type field identifies the type of message contained in this record. Figure 6.4 lists the four message types.

Figure 6.4. SSL Record-Layer Messages Types

Record Type

Value

Description

CHANGE_CIPHER_SPEC

20

switch to the last negotiated cipher suite

ALERT

21

error or CloseNotify messages

HANDSHAKE

22

hello and other connection-initiation messages

APPLICATION_DATA

23

data messages

The major and minor version numbers indicate what version of SSL is being used. SSL 3 has a major version of 3 and a minor version of 0. TLS has a major version of 3 and a minor version of 1.

The length field gives the length in bytes of the data field. The length field does not include the HMAC, padding, or pad length fields.

The data field carries the message data. This field can be empty, as in the case of a ChangeCipherSpec message, or it can carry handshake data, alert messages, or application data.

HMAC is a cryptographically secure message authentication code. This field is used to provide authentication. If any of the previous fields are altered, the receiver will calculate a different HMAC and detect the alteration. Because one of the keys generated during the key exchange is used as an input to the HMAC calculation, an attacker cannot adjust the HMAC in the message to escape detection. As we mentioned earlier, the input to the HMAC includes a sequence number that is used to prevent replay attacks.

Figure 6.3 depicts the HMAC as being a 160-bit SHA1 digest. It is also possible to use an MD5 128-bit digest.

The SSL 3 HMAC is slightly different from that described in RFC 2104 [Krawczyk, Bellare, and Canetti 1997], being based on an earlier draft of that RFC. TLS uses the standard HMAC as defined in RFC 2104.

The padding and pad length fields are used to pad the message to the block size of the encryption algorithm when a block encryption cipher, such as 3DES, is used. When a stream cipher, such as RC4, is used, these fields are not present.

During the first part of the handshake, before the ChangeCipherSpec message, the NULL cipher suite is used, in which case there is no HMAC or padding. This is because the keys are not yet available to generate the HMACs or encrypt the message.


Section 6.4. SSL on the Wire

6.4. SSL on the Wire

Let's look at some SSL exchanges. First, we look at a "normal" SSL session that corresponds to the packet flow depicted in Figure 6.2. Many of the SSL messages contain a great deal of information, so we examine them one at a time.

Handshake Messages

SSL uses handshake messages to negotiate cipher suites and to exchange keying material. All handshake messages begin with a simple 4-byte header (Figure 6.5) that gives the handshake type and the length of the message, exclusive of the header. The values for the handshake types are given in Figure 6.6.

Figure 6.5. The Handshake Header

[View full size image]

Figure 6.6. Handshake Types

Type

Handshake Type

0

HELLO_REQUEST

1

CLIENT_HELLO

2

SERVER_HELLO

11

CERTIFICATE

12

SERVER_KEY_EXCHANGE

13

CERTIFICATE_REQUEST

14

SERVER_HELLO_DONE

15

CERTIFICATE_VERIFY

16

CLIENT_KEY_EXCHANGE

20

FINISHED

Because several layers of encapsulation are involved with the handshake messages, it's beneficial to review what that encapsulation looks like. Figure 6.7 shows the layout of an IP datagram that is carrying an SSL handshake message. The sizes given for the IP and TCP headers assume that neither has any options. Recall that the HMAC and padding will not be present until after a ChangeCipherSpec message is sent.

Figure 6.7. SSL Handshake Message Encapsulation

[View full size image]

The Client Hello

The message format for the ClientHello is shown in Figure 6.8.

Figure 6.8. The ClientHello Message

[View full size image]

Because the SSL message formats are highly irregular and are best thought of as a byte stream, we will alter their graphical presentation a bit in order to make their structure clearer.

The major and minor version are the latest version of SSL that the client understands. This allows the server to determine which protocol version to use for the rest of the session.

Both the client and server will contribute some random data that will be used for key generation. The random data changes with each ClientHello or ServerHello, helping prevent replay attacks. The random data field comprises a standard UNIX 4-byte time valueseconds since midnight, January 1, 1970and 28 random bytes.

The session ID is used to resume a previous session, thereby sidestepping the key-generation phase, which requires considerable resources. We'll see an example of its use later. In the current exchange, it is not used, so the session ID length is set to 0.

Each cipher suite is represented by a 2-byte number (see Figure 6.1). The client sends a list of the cipher suites it is prepared to support, sorted in order of preference.

The server, however, is under no obligation to honor the client's preference and may choose any suite in the client's list.

None of the SSL versions support compression; RFC 3749 [Hollenbeck 2004] describes compression for TLS. Some proprietary implementations and OpenSSL also support compression, but we hardly ever see this capability used. Thus, the compression list contains a single byte of 0, representing NULL.

Now let's look at a ClientHello message. To capture the data, we use ssldump, a tool developed by Eric Rescorla for SSL development, debugging, and his book [Rescorla 2001]. The ssldump program is similar to tcpdump but is specialized to decode SSL packets.

Here is the first message, a ClientHello, in the SSL handshake:

1 1  0.0021 (0.0021) C>SV3.0(47) Handshake
      ClientHello
        Version 3.0
        random[32]=
          3e 5e 6f d3 6b a3 1e ca 45 3f 3a 87 50 92 8e 6b
          c4 9f 74 1e b4 45 b8 44 e7 41 72 31 36 fd e8 63
        cipher suites
        SSL_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_RSA_WITH_IDEA_CBC_SHA
        compression methods
                  NULL

The first line tells us that this is a handshake message from the client to the server (C>S), that it is a version 3.0 message (3.0) of 47 bytes. The first 1 tells us that this is the first connection in the capture, and the second 1 tells us that this is the first record in this connection. The second two fields are the time since the beginning of the capture of this record, and the time since the last record.

The next two lines tells us that this is a ClientHello and that the client understands version 3.0 and below. We also see the client's random number and that the client is willing to use the two cipher suites SSL_RSA_WITH_3DES_EDE_CBC_SHA and SSL_RSA_WITH_IDEA_CBC_SHA. As expected with SSL, the client is unwilling to use any compression methods and lists NULL as the only method.

The Server Hello

As shown in Figure 6.9, the format of ServerHello is similar to that of the ClientHello, except that instead of lists for supported cipher suites and compression methods, only the single chosen value for each is specified by the server.

Figure 6.9. The ServerHello Message

The server's response to our previous ClientHello is

1 2  0.0033 (0.0012) S>CV3.0(74) Handshake
      ServerHello
        Version 3.0
        random[32]=
          3e 5e 6f d3 f8 e3 4d 89 e7 9d 2d 5f 0e b9 8f f8
          77 44 45 95 cb 69 ae 4e 4a 9b c8 29 29 76 da b4
        session_id[32]=
          14 17 3a 80 5e 1d 50 9f 46 1c 38 12 2f e6 d8 3d
          b6 6c 18 59 8b 00 f4 3d a1 1c 2f 22 72 80 37 50
        cipherSuite         SSL_RSA_WITH_3DES_EDE_CBC_SHA
        compressionMeth                    NULL

The server has agreed to the version 3.0 protocol and has chosen to use the SSL_RSA_WITH_3DES_EDE_CBC_SHA cipher suite and NULL compression method. The server has contributed its own random data and has specified a session ID. The client can use this session ID to resume the session later. We'll see an example of this shortly.

Certificate

The next message is the server's certificate. This message is usually a chain of certificates, with the first being the server's own certificate, followed by any authenticating certificates from certificate authorities.

This works as follows: The certificate authority (CA) signs the server's certificate with its private key. The CA's certificate contains the CA's public key, which the client uses to verify that the CA was, in fact, the signer of the server's certificate. The client typically has its own copy of the CA's certificate, making the transaction secure.

The Certificate message is shown in Figure 6.10.

Figure 6.10. The SSL Certificate Message

[View full size image]

The output from ssldump merely reflects the fact that the server has sent its certificate to the client:

1 3  0.0033 (0.0000)  S>CV3.0(571)  Handshake
      Certificate

The Server Hello Done

The next message in our typical SSL session is the ServerHelloDone. Recall that it is used to tell the client that the server has finished its hello sequence and that the client may begin the key-transfer process.

The ServerHelloDone message consists merely of a handshake header with a type of 14, as shown in Figure 6.11.

Figure 6.11. The ServerHelloDone Message

[View full size image]

As with the Certificate message, ssldump merely notes that the message was sent by the server:

1 4  0.0033 (0.0000)  S>CV3.0(4)  Handshake
      ServerHelloDone

The Client Key Exchange

After the server sends its ServerHelloDone message, the client responds with a ClientKeyExchange message. This message contains what SSL calls the PreMasterSecret encrypted with the server's public key that was in its certificate.

In this exchange, we are using RSA for the key exchange. When Diffie-Hellman or Fortezza is used, the details are slightly different.

Figure 6.12 shows the format of the ClientKeyExchange message. The PreMasterSecret is composed of the client's version and 46 cryptographically secure random bytes. Both sides use the PreMasterSecret along with the random bytes from the client and server hellos to generate the MasterSecret, which in turn is used to generate the various keys used by the encryption and digest algorithms.

Figure 6.12. The Client Key Exchange Message

[View full size image]

Cryptographically secure means generated by a cryptographically strong pseudorandom number generator (see RFC 1750 [Eastlake, Crocker, and Schiller 1994]). As the problems with version 2 illustrate, failure to address this issue leads directly to exploits. This is especially important here, because the PreMasterSecret is used as a seed for all the keying material generated during the session.

The message length field specifies 128 bytes. The enlargement from 48 to 128 bytes is the result of the RSA encryption.

One other important point is that the TLS implementation is slightly different. In TLS, the EncryptedPreMasterSecret is defined as a variable array of between 0 and 216 1 bytes and therefore has a 2-byte length prefix.

We see the expansion of the EncryptedPreMasterSecret to 128 bytes in the ssldump output for the ClientKeyExchange message:

1 5  0.0052 (0.0018)  C>SV3.0(132)  Handshake
      ClientKeyExchange
        EncryptedPreMasterSecret[128]=
          cb d0 b0 29 2a 7d 0b 52 52 2b 9a 63 49 62 28 ce
          cf 22 cb 65 c3 0b 2b f6 9b a4 d0 50 20 a6 a3 cd
          c8 73 34 19 c9 cd b7 87 2b 9f 4b 28 b0 86 64 4a
          da 67 8e d4 49 9a 7e b0 41 60 29 46 c1 d8 b6 6c
          13 47 1d 3d cb 39 e7 5b f2 dc 11 19 dc 45 96 a6
          9b 43 36 fe 69 70 41 25 a8 ff 69 50 f9 68 f3 e3
          c6 a5 a4 45 ae 1f 8a ee 25 e0 82 ae a4 21 f1 ff
          ea 3b 2b a1 d1 a3 45 19 f0 55 b6 a3 76 22 36 20

The ChangeCipherSpec Message

After the ClientKeyExchange message, both sides can generate keys for the rest of the session. The next message in our typical session is a ChangeCipherSpec, by which the client indicates that it will henceforth use the new cipher suite:

1 6  0.0052 (0.0000)  C>SV3.0(1)  ChangeCipherSpec

Recall that the ChangeCipherSpec message is one of the four basic record types (Figure 6.4) and is therefore not a Handshake message. The format of the message is just an SSL record (Figure 6.3) with a type of CHANGE_CIPHER_SPEC (20) and a data field of the single byte of value 1.

The Finished Message

Finally, the client indicates that it is finished with the handshake by sending a Finished message. This message is encrypted as promised by the previous ChangeCipherSpec message. Figure 6.13 shows the format of the Finished message.

Figure 6.13. The Finished Message

[View full size image]

The two HMACs are computed over all the previous handshake messages, verifying that the unauthenticated messages were not tampered with. Because the Finished message is encrypted, we normally wouldn't be able to see its contents, but we used our own certificate for the session and therefore know the private key. With access to the private key, ssldump is able to decrypt the PreMasterSecret and generate its own set of keys. Thus, we can see the values of the HMACs in the client's Finished message:

1 7  0.0052 (0.0000)  C>SV3.0(64)  Handshake
      Finished
        md5_hash[16]=
          09 92 f4 f1 16 c6 17 a8 39 a2 c8 c8 44 89 7f df
        sha_hash[20]=
          ae 15 cc e0 8e 5f 13 c3 e2 1e 9c 10 5f 30 8c 24
          cf 6a 83 5e

Note the discrepancy between the message length from the SSL record header (64) and decoded contents (40). The difference is the (SSL record) HMAC and the padding added to fill out the 3DES block size.

The server next sends its own ChangeCipherSpec and Finished messages, and the session is ready for the data transfer stage:

1 8  0.0141 (0.0089)  S>CV3.0(1)  ChangeCipherSpec
1 9  0.0141 (0.0000)  S>CV3.0(64)  Handshake
      Finished
        md5_hash[16]=
          62 57 8c f7 1e 4b 88 81 8b 92 2b 73 dd ce 2e d3
        sha_hash[20]=
          a8 6a b6 04 f1 ed 67 ce d1 c9 aa 1a 82 60 8c f3
          ef 00 61 c4

The client and server exchange application data:

1 10 2.7108 (2.6966)  C>SV3.0(24)  application_data
    -----------------------------------------------------------
    -----------------------------------------------------------
1 11 2.7108 (0.0000)  C>SV3.0(32)  application_data
    -----------------------------------------------------------
    hello
    -----------------------------------------------------------
1 12 2.7125 (0.0016) S>CV3.0(24) application_data
    -----------------------------------------------------------
    -----------------------------------------------------------
1 13 2.7125 (0.0000) S>CV3.0(32) application_data
    -----------------------------------------------------------
    hello
    -----------------------------------------------------------

Record 10 from the client and record 12 from the server do not appear to have any data. These records are called empty fragments and are inserted by OpenSSL as a countermeasure against a vulnerability in version 3 and TLS involving CBC ciphers.

Recall that the SSL data transfer is indistinguishable from a normal TCP data transfer except that the TCP payload appears to be random data. The following tcpdump output is the trace of the preceding four application data records. Notice that there is no obvious indication that this is an SSL session.

In lines 1.4, 1.6, 2.4, and 2.6, we can see the SSL record headers (in boldface). In line 1.6, for example, we see that the SSL record type is 0x17 (2310), indicating that this is application data (see Figure 6.4). The next 2 bytes are the version (3.0), followed by the length, which is 0x0020 (3210). The rest of the SSL record is encrypted, so we can't see the data. Observe that SSL records 10 and 11 were sent in a single TCP segment, as were records 12 and 13.

1   15:06:45.828412 127.0.0.1.1526 > 127.0.0.1.5001: P 265:331(66)
      ack 740 win 57344
      <nop,nop,timestamp 2879023 2878753> (DF)
1.1     4500 0076 5b26 4000 4006 e159 7f00 0001   E..v[&@.@..Y....
1.2     7f00 0001 05f6 1389 d87a 3458 d386 d023   .........z4X...#
1.3     8018 e000 c246 0000 0101 080a 002b ee2f   .....F.......+./
1.4     002b ed21 1703 0000 1848 2ce9 04b5 4071   .+.!.....H,...@q
1.5     f2df faf1 2ab4 eb6f e012 3e68 cf5b db2f   ....*..o..>h.[./
1.6     5217 0300 0020 7821 6be6 0b08 3567 559c   R.....x!k...5gU.
1.7     8d62 74e8 3af8 7f1d 6557 3e82 52f8 7fc1   .bt.:...eW>.R...
1.8     fff8 2b0f 94e6                            ..+...
2   15:06:45.830097 127.0.0.1.5001 > 127.0.0.1.1526: P 740:806(66)
      ack 331 win 57344
      <nop,nop,timestamp 2879023 2879023> (DF)
2.1     4500 0076 5b29 4000 4006 e156 7f00 0001   E..v[)@.@..V....
2.2     7f00 0001 1389 05f6 d386 d023 d87a 349a   ...........#.z4.
2.3     8018 e000 d64b 0000 0101 080a 002b ee2f   .....K.......+./
2.4     002b ee2f 1703 0000 18de 1c26 9d57 55f4   .+./.......&.WU.
2.5     c411 2363 93af e9fc c4b4 1fd8 7956 c557   ..#c........yV.W
2.6     0517 0300 0020 7493 732e b754 89c4 40d1   ......t.s..T..@.
2.7     cd48 6bff 8db9 46dd 6b52 4605 1988 c942   .Hk...F.kRF....B
2.8     52c5 e1b1 0b24                            R....$

Alert Messages and Closure Notification

The final type of record is the Alert message. It consists of 2 bytes carried in the SSL record, as shown in Figure 6.14.

Figure 6.14. The Alert Message

The level field indicates the severity of the alert. It can be either WARNING (1) or FATAL (2). Description is an alert code that indicates what type of alert this is. The values and the protocol versions that support them are given in Figure 6.15.

Figure 6.15. Alert Descriptions

Description

Value

TLS

SSL 3

CLOSE_NOTIFY

0

•

•

UNEXPECTED_MESSAGE

10

•

•

BAD_RECORD_MAC

20

•

•

DECRYPTION_FAILED

21

•

RECORD_OVERFLOW

22

•

DECOMPRESSION_FAILURE

30

•

•

HANDSHAKE_FAILURE

40

•

•

NO_CERTIFICATE

41

•

BAD_CERTIFICATE

42

•

•

UNSUPPORTED_CERTIFICATE

43

•

•

CERTIFICATE_REVOKED

44

•

•

CERTIFICATE_EXPIRED

45

•

•

CERTIFICATE_UNKNOWN

46

•

•

ILLEGAL_PARAMETER

47

•

•

UNKNOWN_CA

48

•

ACCESS_DENIED

49

•

DECODE_ERROR

50

•

DECRYPT_ERROR

51

•

EXPORT_RESTRICTION

60

•

PROTOCOL_VERSION

70

•

INSUFFICIENT_SECURITY

71

•

INTERNAL_ERROR

80

•

USER_CANCELED

90

•

NO_RENEGOTIATION

100

•

1 14 4.9688 (2.2563)  C>SV3.0(24)  Alert
    level           warning
    value           close_notify
1 15 4.9690 (0.0001)  S>CV3.0(24)  Alert
    level           warning
    value           close_notify
1    4.9723 (0.0032)  C>S  TCP FIN
1    4.9726 (0.0002)  S>C  TCP FIN

Resumed Sessions

We saw earlier that the server sent the client a session ID in its ServerHello message. The client can use this ID to bypass much of the handshake negotiation in subsequent sessions.

Although this may seem to have little utility, it arises in a natural way. After a Web server replies to a browser's request for a Web page, it typically closes the TCP connection to indicate an EOF (see Tip 16 of ETCP). If, as is typical of the financial transactions protected by SSL, the client makes another request, being able to resume the session saves time and resources. Although this may not amount to much for the client, it can be significant for busy Web servers.

A resumed session differs from a normal session only in the handshake, as shown in Figure 6.16. The client asks to resume the session by including the session ID from the last session. The server, which has cached the state of that session, agrees by returning the same session ID. We see that the server does not send its certificate and that the client does not send the PreMasterSecret. Both sides will use the existing MasterSecret to generate new keys. Because the new random data from both sides will be used to generate these keys, they will be different from those in the previous incarnation of the session.

Figure 6.16. Data Flow for a Resumed Session Handshake

The following exchange is a resumption of the previous one:

2 1  0.0011 (0.0011)  C>SV3.0(79)  Handshake
      ClientHello
        Version 3.0
        random[32]=
          3e 5e 6f db 15 04 57 00 03 5a a8 ae 30 89 8b 6c
          e9 21 e6 0e 08 23 18 cc 5a 9c 4e bb 20 36 aa f9
        resume [32]=
          14 17 3a 80 5e 1d 50 9f 46 1c 38 12 2f e6 d8 3d
          b6 6c 18 59 8b 00 f4 3d a1 1c 2f 22 72 80 37 50
        cipher suites
        SSL_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_RSA_WITH_IDEA_CBC_SHA
        compression methods
                  NULL
2 2  0.0016 (0.0004)  S>CV3.0(74)  Handshake
      ServerHello
        Version 3.0
        random[32]=
          3e 5e 6f db 3c 45 6f 38 d4 1e 83 79 91 fe 84 6a
          f3 db 09 6e 23 aa 10 96 e0 63 cd c0 81 15 5c 55
        session_id[32]=
          14 17 3a 80 5e 1d 50 9f 46 1c 38 12 2f e6 d8 3d
          b6 6c 18 59 8b 00 f4 3d a1 1c 2f 22 72 80 37 50
        cipherSuite         SSL_RSA_WITH_3DES_EDE_CBC_SHA
        compressionMethod                   NULL
2 3  0.0016 (0.0000)  S>CV3.0(1)  ChangeCipherSpec
2 4  0.0016 (0.0000)  S>CV3.0(64)  Handshake
      Finished
        md5_hash[16]=
          c1 c7 66 99 cd 32 9a 20 7d d6 e2 82 e1 67 1f a0
        sha_hash[20]=
          5b 04 2f df a1 bb 47 75 44 35 20 62 4d 56 e1 66
          54 54 38 b9
2 5  0.0018 (0.0002)  C>SV3.0(1)  ChangeCipherSpec
2 6  0.0018 (0.0000)  C>SV3.0(64)  Handshake
      Finished
        md5_hash[16]=
          5c 5b 69 d3 d1 59 86 7f 2a d3 40 3e a1 6e 0f b5
        sha_hash[20]=
          48 ac 60 8e 45 39 b1 c0 3e b1 86 1f eb ec 9e 89
          5d fa d7 f7
2 7  4.5853 (4.5834)  C>SV3.0(24)  application_data
    -----------------------------------------------------------
    -----------------------------------------------------------
2 8  4.5853 (0.0000)  C>SV3.0(40)  application_data
    -----------------------------------------------------------
    hello again
    -----------------------------------------------------------
2 9  4.5870 (0.0016)  S>CV3.0(24)  application_data
    -----------------------------------------------------------
    -----------------------------------------------------------
2 10  4.5870 (0.0000)  S>CV3.0(40)  application_data
    -----------------------------------------------------------
    hello again
    -----------------------------------------------------------
2 11 6.2698 (1.6828)  C>SV3.0(24)  Alert
    level           warning
    value           close_notify
2 12 6.2700 (0.0001)  S>CV3.0(24)  Alert
    level           warning
    value           close_notify
2    6.2730 (0.0029)  C>S TCP FIN
2    6.2732 (0.0002)  S>C TCP FIN

Version 2 Client Hello

In order to interoperate with version 2 servers, many browsers will start the handshake with a version 2 ClientHello message that indicates their ability to support version 3. If the server also supports version 3, it will respond with a version 3 ServerHello, and the rest of the session will take place using the version 3 protocol. If the server responds with a version 2 ServerHello, the browser will continue to use the version 2 protocol.

Some version 2 browsers won't accept a ClientHello with a version number other than 2. In this case, the handshake fails, and a secure connection cannot be established.

The version 2 SSL Record and ClientHello format is shown in Figure 6.17.

Figure 6.17. The Version 2 Record and ClientHello Format

[View full size image]

The following session is between a Mozilla 1.2 browser and a bank's secure Web site. We can't tell for sure which Web server the bank is using, because the traffic is encrypted, but the rest of the bank's Web site is hosted by Netscape-Enterprise Server.

1 1  0.0512 (0.0512)  C>S SSLv2 compatible client hello
  Version 3.1
  cipher suites
  SSL2_CK_RC4
  SSL2_CK_RC2
  SSL2_CK_3DES
  SSL2_CK_DES
  SSL2_CK_RC4_EXPORT40
  SSL2_CK_RC2_EXPORT40
  TLS_RSA_WITH_RC4_128_MD5
  Unknown value 0xfeff
  TLS_RSA_WITH_3DES_EDE_CBC_SHA
  Unknown value 0xfefe
  TLS_RSA_WITH_DES_CBC_SHA
  TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
  TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
  TLS_RSA_EXPORT_WITH_RC4_40_MD5
  TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
1 2  0.1077 (0.0564)  S>CV3.0(1286)  Handshake
      ServerHello
        Version 3.0
        random[32]=
          00 00 07 98 0d 95 99 80 1f 6c d2 f9 20 9a ed cf
          f6 5c 95 f8 b1 d5 3f cb b8 49 4d a5 c8 89 63 99
        session_id[32]=
          36 79 c6 ba c7 40 1b dc f3 0b 95 a7 e5 ed b9 e5
          60 65 f0 48 85 25 80 b2 f9 e4 33 18 b7 cf 64 7d
        cipherSuite         SSL_RSA_WITH_RC4_128_MD5
        compressionMethod                   NULL
      Certificate
      ServerHelloDone
1 3  0.1229 (0.0152)  C>SV3.0(132)  Handshake
      ClientKeyExchange
        EncryptedPreMasterSecret[128]=
          c2 61 ad 31 a3 3e 2e 8b 6f 77 81 e1 8a 76 b1 20
          76 54 fa 11 57 14 e7 4e f8 85 c1 2e a9 99 eb 5c
          7b d5 54 04 7c 04 70 0b b7 41 39 0c c6 78 05 39
          ce 83 40 31 15 95 9d 7f 03 c7 06 3d a8 8b 13 5d
          4a 82 8a 53 1a 06 e6 25 f3 29 14 21 04 1b a0 f4
          bb bd 00 b3 ca 60 11 07 5e 36 ba 20 1b f4 05 b6
          4e e7 b2 f2 91 14 c0 68 78 af 23 83 8f 9e 30 3a
          63 a6 2b 20 13 3c ca 76 ab 85 7e dd 09 64 7e 8a
1 4  0.1229 (0.0000)  C>SV3.0(1)  ChangeCipherSpec
1 5  0.1229 (0.0000)  C>SV3.0(56)  Handshake
1 6  0.1828 (0.0599)  S>CV3.0(1)  ChangeCipherSpec
1 7  0.1828 (0.0000)  S>CV3.0(56)  Handshake
1 8  0.1842 (0.0013)  C>SV3.0(473)  application_data
1 9  0.2371 (0.0529)  S>CV3.0(253)  application_data
1 10 0.2399 (0.0027)  S>CV3.0(18)  Alert
1    0.2409 (0.0009)  S>C  TCP FIN
1 11 0.2459 (0.0049)  C>SV3.0(18)  Alert
1    0.2460 (0.0000)  C>S  TCP FIN

Mozilla sends a version 2 ClientHello but offers to negotiate at version 3.1 (TLS) or lower. The cipher suites beginning with SSL2_ are those that are defined in version 2. The others are the normal version 3.0/3.1 cipher suites.

The server responds with a version 3 ServerHello, saying that it will negotiate with version 3 using RSA, 128-bit RC4, and MD5. The rest of the session proceeds in a normal version 3 manner.

SSL record 2 contains three handshake messages: ServerHello, Certificate, and ServerHelloDone. This behavior is normal. An SSL record can contain multiple messages as long as they are all the same record type: Handshake, in this case. It is also legal for a single message to be split across more than one SSL record, but this does not happen in practice [Rescorla 2001].

Client Authentication

It is possible for the server to require that the client authenticate itself just as the server must. To do this, the server issues a CertificateRequest, and the client replies with its certificate and a CertificateVerify message. Figure 6.18 shows the handshake portion of the data flow. The handshake begins with the normal exchange of hello messages, followed by the server's certificate. Then, instead of sending the ServerHelloDone, the server sends a CertificateRequest, asking the client to send its own certificate to the server. This is our first example of the necessity for the ServerHelloDone message; the server has an extra message to send before it is done with its hello sequence.

Figure 6.18. Client Authentication Handshake

The client responds with Certificate and ClientKeyExchange messages. At this point, both sides can generate their keying material. Before sending the ChangeCipherRequest, however, the client sends one additional messagethe CertificateVerify messagea digest of the previous handshake messages, encrypted with the client's private key. The server then decrypts the message with the client's public key from its certificate and verifies that the digest is correct. In this way, the client verifies that it is the owner of the certificate, as only the owner will know the private key. This is important, because the certificate is sent unencrypted and could easily be captured and reused by an attacker. As before, the random values in the ClientHello and ServerHello messages prevent a replay attack by ensuring that the digest will differ from any other handshake between the peers, even if everything else is the same.

We can learn a little more about these messages by watching them on the wire.

We've shortened the ssldump output a bit by inhibiting the printing of the random values and EncryptedPreMasterSecret. These values were, of course, still sent.

1 1  0.0050 (0.0050)  C>S  Handshake
      ClientHello
        Version 3.0
        cipher suites
        SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        SSL_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_DHE_DSS_WITH_RC4_128_SHA
        SSL_RSA_WITH_RC4_128_SHA
        SSL_RSA_WITH_RC4_128_MD5
        SSL_DHE_DSS_WITH_RC2_56_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
        SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
        SSL_RSA_EXPORT1024_WITH_RC4_56_MD5
        SSL_DHE_RSA_WITH_DES_CBC_SHA
        SSL_DHE_DSS_WITH_DES_CBC_SHA
        SSL_RSA_WITH_DES_CBC_SHA
        SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
        SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
        SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
        SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
        SSL_RSA_EXPORT_WITH_RC4_40_MD5
        compression methods
                  NULL
1 2  0.0056 (0.0005)  S>C  Handshake
      ServerHello
        Version 3.0
        session_id[32]=
          1c f7 13 97 e5 fb e4 7f d8 43 4c 78 dc 7b 68 22
          86 a2 e1 f2 04 d5 bd c6 7b 45 3d 91 11 64 36 4d
        cipherSuite         SSL_RSA_WITH_3DES_EDE_CBC_SHA
        compressionMethod                   NULL
1 3  0.0056 (0.0000)  S>C  Handshake
      Certificate
1 4  0.0056 (0.0000)  S>C  Handshake
      CertificateRequest
        certificate_types                   rsa_sign
        certificate_types                   dss_sign
      ServerHelloDone
1 5  0.0179 (0.0122)  C>S  Handshake
      Certificate
1 6  0.0179 (0.0000)  C>S  Handshake
      ClientKeyExchange
1 7  0.0179 (0.0000)  C>S  Handshake
      CertificateVerify
        Signature[128]=
          87 d7 11 5e fa fa ed e1 87 d5 25 5e 19 71 35 e6
          c3 c8 5f c6 ed de ee b8 c1 b6 9c 50 97 45 33 b2
          5f c7 6f 91 d6 db 7c a4 ed 05 b0 1d 16 8a d4 37
          4c c1 50 92 61 6b fd 3d 1c 71 ea e5 d1 a5 d5 89
          8f d4 b5 c1 d2 d7 ed 33 37 82 b4 93 9c e1 07 3a
          a9 dd d5 20 82 2e b0 b5 68 20 c6 e3 2d d5 b4 59
          14 74 dc 79 a7 73 13 88 af a0 75 1d 5c 81 9b 59
          c9 67 3a e2 61 50 b8 f6 7e 62 64 7b 6f 55 09 d0
1 8  0.0179 (0.0000)  C>S  ChangeCipherSpec
1 9  0.0179 (0.0000)  C>S  Handshake
1 10 0.0242 (0.0063)  S>C  ChangeCipherSpec
1 11 0.0242 (0.0000)  S>C  Handshake

In record 4, the CertificateRequest includes a list of certificate types that the server is willing to accept. In this case, the server will accept either an RSA or a DSS signed certificate. Figure 6.19 shows the format of the CertificateRequest.

Figure 6.19. The CertificateRequest

[View full size image]

As shown in the figure, the server can also specify which certificate authorities it is willing to accept. This capability was not used in the previous exchange.

Diffie-Hellman Key Exchange

Until now, all our example sessions have used RSA key exchange. With RSA key exchange, the client generates a random PreMasterSecret and encrypts it with the server's public key, which it obtains from the server's certificate.

It is also possible to use Diffie-Hellman to exchange keys. With Diffie-Hellman, the process is different. The usual method is for the server to generate a Diffie-Hellman key, sign it with its DSS key, and send it to the client. The client also generates a Diffie-Hellman key and sends it to the server. Both sides then compute the Diffie-Hellman shared secret from these keys and use it as the PreMasterSecret. The server can also use a permanent Diffie-Hellman key, in which case the key is included with the server's certificate. We see this exchange of messages in Figure 6.20. Note that the server sends its Diffie-Hellman key in the ServerKeyExchange message right after sending its certificate.

Figure 6.20. Diffie-Hellman Key Exchange

The format of the ServerKeyExchange is given in Figure 6.21. In addition to the Diffie-Hellman key, the message contains the prime modulus and group generator to be used with the Diffie-Hellman exchange.

Figure 6.21. ServerKeyExchange (Diffie-Hellman)

[View full size image]

We can see the messages by examining the output of ssldump:

1 1  0.0041 (0.0041)  C>SV3.0(83)  Handshake
      ClientHello
        Version 3.0
        random[32]=
          3e 7e 03 ef c9 db 73 e5 3f 85 6d 79 0d c0 d4 81
          d6 db ea 8f 92 14 68 ac 6f db 2e 83 a9 02 1a 3b
        cipher suites
        SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        SSL_RSA_WITH_3DES_EDE_CBC_SHA
        SSL_DHE_DSS_WITH_RC4_128_SHA
        SSL_RSA_WITH_RC4_128_SHA
        SSL_RSA_WITH_RC4_128_MD5
        SSL_DHE_DSS_WITH_RC2_56_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_RC4_56_SHA
        SSL_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_DES_CBC_SHA
        SSL_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5
        SSL_RSA_EXPORT1024_WITH_RC4_56_MD5
        SSL_DHE_RSA_WITH_DES_CBC_SHA
        SSL_DHE_DSS_WITH_DES_CBC_SHA
        SSL_RSA_WITH_DES_CBC_SHA
        SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
        SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
        SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
        SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5
        SSL_RSA_EXPORT_WITH_RC4_40_MD5
        compression methods
                  NULL
1 2  0.0069 (0.0028)  S>CV3.0(74)  Handshake
      ServerHello
        Version 3.0
        random[32]=
          3e 7e 03 ef bb 3b 30 7d d5 02 ea f4 d4 e7 c5 6a
          61 9f 93 ca 0c 4c d1 98 3d 67 9f e3 7a 28 e2 a1
        session_id[32]=
          b8 9b 8d 85 19 56 8a 28 c8 16 fc c6 cc 55 a0 1e
          ba 24 4b 73 63 1d d7 b6 7c fd 5d 51 1e 90 8c 4e
        cipherSuite         SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
        compressionMethod                   NULL
1 3  0.0069 (0.0000)  S>CV3.0(767)  Handshake
      Certificate
1 4 0.1035 (0.0965)   S>CV3.0(189)  Handshake
     ServerKeyExchange
       params
         DH_p[64]=
           da 58 3c 16 d9 85 22 89 d0 e4 af 75 6f 4c ca 92
           dd 4b e5 33 b8 04 fb 0f ed 94 ef 9c 8a 44 03 ed
           57 46 50 d3 69 99 db 29 d7 76 27 6b a2 d3 d4 12
           e2 18 f4 dd 1e 08 4c f6 d8 00 3e 7c 47 74 e8 33
         DH_g[1]=
           02
         DH_Ys[64]=
           9d 5d 2e ac b2 95 20 83 a0 87 37 68 f6 be 25 19
           d6 eb e0 21 fd 38 88 83 d6 cb 84 6f 10 d2 98 e5
           72 5b ef a4 52 23 65 9d b1 c4 22 21 1a 90 d2 e7
           53 f0 8b 63 43 12 43 22 ef 7d 45 77 1e 67 79 9b
       signature[48]=
         30 2e 02 15 00 ad b4 23 61 61 1e 44 35 da 8e f4
         9b 5b d7 c0 cd e0 c6 35 07 02 15 00 98 d3 df d7
         04 48 d5 d3 ed bb fe 5d e4 30 e5 31 fb 5f 0b c1
1 5  0.1035 (0.0000)  S>CV3.0(4) Handshake
      ServerHelloDone
1 6  0.1106 (0.0071)  C>SV3.0(70) Handshake
      ClientKeyExchange
        DiffieHellmanClientPublicValue[64]=
          7e 80 ba 59 2e 63 d2 e6 ca f4 03 c9 8a c8 16 02
          e1 3c 39 61 97 a0 61 d0 f3 30 57 a7 a9 5c a4 83
          40 35 83 d6 7a 9d 1f 72 d7 d6 35 96 27 52 a6 60
          5c 75 92 ec 04 c8 6f cd d2 10 1d b3 1c ca 0a 90
1 7  0.1106 (0.0000)  C>SV3.0(1)  ChangeCipherSpec
1 8  0.1106 (0.0000)  C>SV3.0(64)  Handshake
1 9  0.1131 (0.0024)  S>CV3.0(1)  ChangeCipherSpec
1 10 0.1131 (0.0000)  S>CV3.0(64)  Handshake

The ServerKeyExchange is in record 4. As indicated in Figure 6.21, the server sends the prime modulus (DH_p) and group generator (DH_g) as well as its key (DH_Ys) and the signature. Because the client must use the same prime modulus and group generator, it merely responds with its key in record 6. The rest of the session proceeds as usual.


Section 6.5. OpenSSL

6.5. OpenSSL

The most common open source implementation of the SSL protocol is OpenSSL, a library that implements the SSL protocol and other cryptographic functions. OpenSSL also has a command line front end that allows the user to perform various administrative tasks, such as making and signing certificates, making RSA and DSA keys, generating Diffie-Hellman parameters, calculating various message digests, encrypting and decrypting with several ciphers, and handling S/MIME signed or encrypted mail. Versions are available for virtually all UNIX systems, Windows, and VMS.

The OpenSSL front end also has s_client and s_server functions that implement configurable SSL-enabled client and server programs. These applications are convenient for testing and debugging SSL applications. Indeed, our example traces of client authentication and Diffie-Hellman key exchange were generated with these programs.

The OpenSSL library and command line front end are too large to cover here. Fortunately, [Viega, Messier, and Chandra 2002] covers the topic in detail. One can also find documentation, source code, and further information about OpenSSL at the OpenSSL Web site <http://www.openssl.org>.

In the next section, we'll find it convenient to have an SSL-aware echo server to explore stunnel, so let's take the opportunity here to briefly explore programming with the OpenSSL library. As we'll see, it follows the familiar TCP server paradigm but with calls specific to SSL. Thus, for example, we'll call SSL_read instead of read.

Our short example exercises only the most basic aspects of the API and is in no way representative of the full functionality. [Rescorla 2001] and [Viega, Messier, and Chandra 2002] cover the material in detail and should be consulted for more information about programming with SSL.

We begin with the includes, defines, and main function in Figure 6.22. This section initializes SSL, sets up our SSL context, and arranges for the application to listen for and accept connections.

Figure 6.22. An SSL-aware Echo Server (main)

[View full size image]

Initialization

19 | We include the necessary SSL headers and the etcp.h header, which contains the definitions for the library code from ETCP. The ERROR macro simply retrieves a printable version of the SSL error information and calls the error function from ETCP.
17 | The INIT macro sets the program name for use by the error function.
1820 | We initialize SSL and load the error strings for use by the ERROR macro.
2123 | We create an SSL context for a server and specify that the server should accept only SSL 3 connections. The OpenSSL library is very flexible about what versions it will accept, but here we are simply insisting on SSL 3.
2428 | Next, we load our certificate chain and private key. As indicated by the SCERT define, these reside in the file sslecho.pem.

Accept Connections

29 | We call the tcp_server function from ETCP to obtain a listening socket on port 4134.
3234 | We accept a TCP-level connection as usual.
3537 | OpenSSL uses an I/O abstraction called a BIO, which hides the underlying I/O details from the application and allows it to transparently handle normal I/O, encrypted I/O, and SSL connections. These lines create a BIO for our new socket connection.
3840 | Next, we create a new SSL context for our connection. The new context will inherit the settings, such as protocol version, of our original context that we obtained in line 21.
41 | The call to SSL_set_bio connects our new SSL context to the socket BIO that we created in line 35.
4243 | We complete the client's connection with the call to SSL_accept. This function waits for the client to initiate the SSL handshake sequence and returns when the handshake is complete or has failed because of errors.
4447 | At this point, we have an SSL session established, and we call the echo function (Figure 6.23) to process the client's input. When echo returns, we shut down the SSL session, release the SSL context, close the TCP connection, and wait for another client. Note that this simple server can handle only one client at a time.

Figure 6.23. An SSL-Aware Echo Server (echo)

[View full size image]

As we see, the echo function looks just like it would in a normal TCP connection except that we call SSL_read and SSL_write instead of read and write, and we pass them a pointer to the SSL context instead of a socket descriptor.

We test sslecho by running it on linux and connecting to it with s_client from bsd. We've wrapped the Session-ID and Master-Key to make them fit on the page.

bsd:~
$ openssl s_client -connect linux:4134 -ssl3 -CAfile rootcert.pem
CONNECTED(00000003)
depth=1 /C=US/ST=Florida/L=Tampa/O=Text CA/CN=bsd.jcs.local
verify return:1
depth=0 /C=US/ST=Florida/L=Tampa/O=sslecho/CN=linux.jcs.local
verify return:1
---
Certificate chain
 0 s:/C=US/ST=Florida/L=Tampa/O=sslecho/CN=linux.jcs.local
   i:/C=US/ST=Florida/L=Tampa/O=Text CA/CN=bsd.jcs.local
 1 s:/C=US/ST=Florida/L=Tampa/O=Text CA/CN=bsd.jcs.local
   i:/C=US/ST=Florida/L=Tampa/O=Text CA/CN=bsd.jcs.local
---
Server certificate
-----BEGIN CERTIFICATE-----
MIICPzCCAaigAwIBAgIBCTANBgkqhkiG9w0BAQUFADBZMQswCQYDVQQGEwJVUzEQ
MA4GA1UECBMHRmxvcmlkYTEOMAwGA1UEBxMFVGFtcGExEDAOBgNVBAoTB1RleHQg
Q0ExFjAUBgNVBAMTDWJzZC5qY3MubG9jYWwwHhcNMDMwMzMxMjAwMjQyWhcNMDQw
MzMwMjAwMjQyWjBbMQswCQYDVQQGEwJVUzEQMA4GA1UECBMHRmxvcmlkYTEOMAwG
A1UEBxMFVGFtcGExEDAOBgNVBAoTB3NzbGVjaG8xGDAWBgNVBAMTD2xpbnV4Lmpj
cy5sb2NhbDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1m/WQACKxoYAuDFi
86a9wfAQtWk0jPfWCZhmnd2lkF5Y+wadWSF1+6yrhlaDV6+FHlOQRffpP2ax8+f9
WcGI7oYTPHlVyVBYrloy1W6qp/D9LIi5iRydPpUna8ypH17AmdVleR4tZNNj3ZmP
HyIdLy4b+TlsxR6zAaAaB1YhW8MCAwEAAaMVMBMwEQYJYIZIAYb4QgEBBAQDAgZA
MA0GCSqGSIb3DQEBBQUAA4GBAEvnIpT5qcPba6XD6jm3mgQ2yd7Xwu1Z17u5TOw1
pBXpMtaw6thkXVxBP7vJQccy/a1HUiDE1QQ6kqhZ+DQ8V73MFaz0PlkRP8Q/L6V/
74mPE1HmnKeUIHHtWh1XZbs4NC8KhnPiGOCPI03Qoze27g9EBx2UZnB47zHRl1AR
7CXD
-----END CERTIFICATE-----
subject=/C=US/ST=Florida/L=Tampa/O=sslecho/CN=linux.jcs.local
issuer=/C=US/ST=Florida/L=Tampa/O=Text CA/CN=bsd.jcs.local
---
No client certificate CA names sent
---
SSL handshake has read 1497 bytes and written 300 bytes
---
New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA
Server public key is 1024 bit
SSL-Session:
    Protocol : SSLv3
    Cipher : DES-CBC3-SHA
    Session-ID: 57B151EA5F439BB9FEB607DEF7D803B44706FD602A9FD208
                12516A154B35BA20
    Session-ID-ctx:
    Master-Key: 1D91D5BB779D29BF01006D00A0B6FD63D79CD31E1D13B423
                D44C47EDA14E24EB4B5C50C02B698C85876971F16FDD6DE7
    Key-Arg : None
    Start Time: 1049151347
    Timeout : 7200 (sec)
    Verify return code: 0 (ok)
---
Hello linux!
Hello linux!
^D
DONE
bsd:~

Most of the output is information that s_client prints about the SSL session. We see that s_client has verified the sslecho server's certificate, that no client certificate was requested, and that we are using SSL 3 as expected. At the bottom of the session's output, we see our Hello linux! echoed from the server. We end the session by sending a ^D as an EOF.


Section 6.6. The stunnel Program

6.6. The stunnel Program

One problem with the examples we have looked at so far is that the applications are all SSL-aware. That is, they have support for SSL compiled into the application. We would like a way to use SSL to secure applications that know nothing of SSL.

Fortunately, there is software that does exactly that: stunnel. The stunnel program provides a secure tunnel between two applications that are not SSL-aware or between two applications only one of which is SSL-aware. The program is often used, for instance, to secure POP3, IMAP, NNTP, or SMTP servers without changing the code of the servers themselves.

The stunnel program depends on the OpenSSL library to provide its SSL functionality. Its role is to provide a convenient tunnel endpoint for applications that have no SSL capability of their own. This is illustrated in Figure 6.24, which shows stunnel connecting (A) two SSL-unaware applications and (B) an SSL-unaware application with an application that is SSL-aware.

Figure 6.24. Using stunnel to Connect Applications

Using stunnel

Let's try some concrete examples of the two situations shown in Figure 6.24. For our SSL-unaware client, we'll use netcat. For our SSL-aware server, we'll use the SSL echo server that we developed in the previous section. For our SSL-unaware server, we'll use a shell script that implements a simple echo server (Figure 6.25).

Figure 6.25. A Simple Echo Server

[View full size image]

To form an SSL tunnel between netcat and echoit, we need two stunnel processesone for each end of the tunnel, just as in Figure 6.24 (A). Let's start with the server end of the tunnel. We use the stunnel configuration file shown in Figure 6.26.

Figure 6.26. The Server's stunnel Configuration File

[View full size image]

3 | The cert parameter points to the server's certificate. The server will send this certificate to the client in the Certificate handshake.
58 | These lines establish a chroot jail for stunnel to run in. Everything that stunnel needs to run must be in this jail, because nothing outside the /var/tmp/stunnel subdirectory can be accessed by stunnel or any applications it calls.
1011 | The ciphers parameter lists the ciphers that the server will support. We have also specified the DONT_INSERT_EMPTY_FRAGMENTS option to prevent the server from including empty fragments in the application records.
1316 | These lines define a service and tell stunnel how to handle requests for it. The [echo] names the service and has no real significance other than to serve as a delimiter between services and as a tag for logging diagnostics. The accept parameter tells stunnel to listen for requests for the echo service on TCP port 5001. The exec parameter tells stunnel to exec echoit when there is a connection on port 5001. Notice that the path for echoit is relative to the jail. Because echoit takes no arguments, the execargs parameter lists only arg0, the application name.

The configuration file for the client stunnel is similar, as shown in Figure 6.27.

Figure 6.27. The Client's stunnel Configuration File

[View full size image]

89 | Instead of specifying a certificate to send as we did in stunnel.server, we request that stunnel verify the server's certificate, using the root certificate (rootcert.pem) from our mini-CA, Text CA.
13 | We inform stunnel that this invocation will be playing the client's role.
1523 | We define three services: echo-r for remote echo, echo-l for local echo, and sslecho. The [echo-r] service accepts connections from an SSL-unaware application on TCP port 5000 and connects to its peer stunnel running on host linux on port 5001. The [echo-l] service is similar except that it accepts connections on port 5002 and connects to an stunnel running on the same machine.

The utility of this last service is limited, of course. Local services like this are useful for testing before moving the server application to a remote machine.

We will use the [sslecho] service to connect to our sslecho server on linux, by connecting to port 5003 on the local machine.

We now have everything we need to try the two situations in Figure 6.24. First, we'll use stunnel to provide a secure connection from a netcat session on bsd to the echoit script on linux. We begin by starting stunnel on both machines. On bsd, we start the client side:

bsd# stunnel stunnel.client

On linux, we start the server side. We also start sslecho, for our next demonstration:

linux:# stunnel stunnel.server
linux:# sslecho

In another window on bsd, we use netcat to connect to the client side of the tunnel. We type two lines and note that they are echoed back to us by echoit:

bsd:~
$ nc -v localhost 5000
localhost [127.0.0.1] 5000 (commplex-main) open
Hello echoit on linux!
Hello echoit on linux!
bye
bye
^C punt!
bsd:~

Although not shown here, an ssldump TRace taken during the session shows the two stunnels connecting as usual and passing the application data.

Using the same client stunnel invocation, we can also demonstrate an SSL-unaware application talking to one that is SSL-aware:

bsd:~
$ nc -v localhost 5003
localhost [127.0.0.1] 5003 (?) open
Hello from bsd
Hello from bsd
^C punt!
bsd:~

Notice that this is essentially the same as the echoit demonstration except that we connect to local port 5003. That causes the client stunnel on bsd to connect directly to the sslecho program running on linux.

Building a VPN with stunnel

SSL is nominally a protocol between two applications, and the examples we have explored so far all reflect that. It is possible, however, to use stunnel to connect two networks. To make things clear, Figure 6.28 shows a portion of our test network. We are going to connect the 192.168.123.0/24 network segment with the 192.168.122.0/24 network segment by establishing a PPP tunnel over SSL between hosts bsd and linux. We have labeled the PPP connection "virtual" because the actual flow of the PPP data is through the SSL tunnel over the 172.30.0.0/24 network segment, as shown by the shaded path.

Figure 6.28. Tunneling PPP over SSL

To do this, we'll tunnel the PPP connection through stunnel in a way similar to Figure 6.24 (A). First, we add a new service to our stunnel.client configuration file:

[sslvpn]
accept = 5010 # local stunnel is listening here
connect = linux:5011 # remote stunnel is listening here

Rather than use the same server configuration file, we simplify things a bit by not arranging for a chroot jail. Our new stunnel server configuration file is as shown in Figure 6.29.

Figure 6.29. The stunnel Configuration File for the VPN Server

[View full size image]

38 | These lines are just like those in stunnel.server, except that we don't create the chroot jail.
1013 | We define our new service. When the peer stunnel on bsd connects to port 5011, we will exec the PPP daemon, pppd. The notty parameter tells pppd not to use a serial port, as it normally would, but to communicate with its peer PPP process through STDIN and STDOUT.

The pppd daemon does this by opening a pseudoterminal (see [Stevens 1992]), which allows the rest of the daemon to believe that it is communicating over a serial port.

The 10.0.0.4:10.0.0.1 tells pppd that the local interface for the PPP connection will have address 10.0.0.4 and that the remote interface's address is 10.0.0.1.

This is all the configuration that is necessary on linux. On bsd, however, things are more complicated. Most UNIX implementations implement PPP in the kernel, as Linux does. FreeBSD, however, uses a user-mode PPP process called ppp. The TCP/IP stack is connected to this process by the tunnel driver, just as gtunnel is. The ppp program is very flexible: It can handle ISDN, PPPoE, NAT, proxy ARP, and several other protocols in addition to PPP. This flexibility requires the use of configuration files, which complicates our side of the VPN a little. In a manner reminiscent of the stunnel configuration file, one can define multiple ppp services and then refer to them by name. For simplicity, we define only the sslvpn service, although the same configuration file could have services for any of the protocols supported by ppp. Our ppp configuration file is given in Figure 6.30.

Figure 6.30. The ppp Configuration File

[View full size image]

2 | This line merely sets the logging level. Here, we are requesting a great deal of information, which is handy for debugging but is probably overkill in a production environment.
48 | These are the parameters for our PPP session. Line 5 tells ppp to communicate over TCP port 5010 on the local host rather than the usual serial port. The set dial command is used to tell ppp to initiate a session with its peer and to specify the dialing chat script. Because we won't be dialing anything, we do not specify an argument. By setting the timeout to 0, we disable the idle timeout and keep the PPP connection up even if there is no traffic. Finally, the set ifaddr command sets the addresses of the local and peer interfaces.

There is one more configuration file to deal withthe ppp.linkup script (Figure 6.31). This file is executed by ppp when the PPP link comes up. We will use this script to add a route to our peer network. We could do this by hand, as we will on the linux side, but the script is a handy way of adding the route automatically.

Figure 6.31. Adding a Route When the Link Comes Up

[View full size image]

Linux offers a similar capability with the ip-up script. The details of how it works depend on which of the various Linux distributions is in use. We will add the route manually on linux to avoid bogging down in these details and to make explicit the need to add the route.

The HISADDR in line 2 will be replaced by the peer's interface address. In this case, we already know it, of course, but sometimes it's not known until the link comes up.

We now have everything in place to establish our VPN and try it out. First, we start stunnel on linux, where it will listen for a connection from its peer stunnel on bsd:

linux:# /usr/local/sbin/stunnel stunnel.vpn

Next, we start stunnel and ppp on bsd. When ppp starts, it connects to stunnel, which establishes the SSL connection with its peer on linux. When the stunnel on linux sees the connect, it starts the pppd daemon:

bsd# stunnel stunnel.client
bsd# ppp -background sslvpn
Working in background mode
Using interface: tun0
PPP enabled

We see from the PPP enabled that the PPP tunnel has been established. Although nothing in the screen capture shows it, this PPP tunnel is being carried inside the SSL tunnel, an example of tunneling an interface-layer protocol inside a transport-layer protocol.

We can now test the tunnel. On linux, we do this by adding a route to the 192.168.123.0/24 network and pinging bsd on its 192.168.123.1 interface:

linux: # route add -net 192.168.123.0/24 gw 10.0.0.1
linux: # ping 192.168.123.1
PING 192.168.123.1 (192.168.123.1) from 10.0.0.4 :
    56(84) bytes of data.
64 bytes from 192.168.123.1: icmp_seq=1 ttl=64 time=2.64 ms
64 bytes from 192.168.123.1: icmp_seq=2 ttl=64 time=2.48 ms
64 bytes from 192.168.123.1: icmp_seq=3 ttl=64 time=2.47 ms
64 bytes from 192.168.123.1: icmp_seq=4 ttl=64 time=2.42 ms
...

On bsd, we do the same except that we don't need to set the route, because it was already supplied by the ppp.linkup file:

bsd# ping 192.168.122.1
PING 192.168.122.1 (192.168.122.1): 56 data bytes
64 bytes from 192.168.122.1: icmp_seq=0 ttl=64 time=7.063 ms
64 bytes from 192.168.122.1: icmp_seq=1 ttl=64 time=2.354 ms
64 bytes from 192.168.122.1: icmp_seq=2 ttl=64 time=2.283 ms
64 bytes from 192.168.122.1: icmp_seq=3 ttl=64 time=2.339 ms
...

It is worth considering what the data in our tunnel looks like. As we noted, we are tunneling an interface-layer protocol, which in turn carries higher-layer protocols, inside a transport-layer protocol. Figure 6.32 shows the packet layout for the pings on our VPN.

Figure 6.32. SSL VPN Packet Encapsulation

[View full size image]

Here is one ping captured by ssldump during the test of our VPN. The first two bytes are the PPP header: The 7e is a flag byte that separates PPP frames, and the 21 is the PPP protocol number indicating that this PPP frame contains an IP packet. The next 20 bytes, beginning with the 45, are the IP header. The following byte, in boldface, is the start of the ICMP packet. Notice that it is 08 (echo request) in the first SSL record, and 00 (echo reply) in the second. The last 3 bytes are the PPP trailer comprising a 2-byte CRC and another flag byte.

1 40 72.1196 (11.9504)  S>CV3.0(112)  application_data
  ---------------------------------------------------------------
  7e 21 45 00 00 54 72 7b 40 00 40 01 82 80 0a 00    ~!E..Tr{@.@.....
  00 04 c0 a8 7b 01 08 00 56 21 63 11 01 00 3c 5a    ....{...V!c...<Z
  90 3e 7a 31 0c 00 08 09 0a 0b 0c 0d 0e 0f 10 11    .>z1............
  12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21    .............. !
  22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31    "#$%&'()*+,-./01
  32 33 34 35 36 37 92 51 7e                         234567.Q~
  ---------------------------------------------------------------
1 41 72.1209 (0.0013)  C>SV3.0(112)  application_data
  ---------------------------------------------------------------
  7e 21 45 00 00 54 36 fa 40 00 40 01 be 01 c0 a8    ~!E..T6.@.@.....
  7b 01 0a 00 00 04 00 00 5e 21 63 11 01 00 3c 5a    {.......^!c...<Z
  90 3e 7a 31 0c 00 08 09 0a 0b 0c 0d 0e 0f 10 11    .>z1............
  12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21    .............. !
  22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31    "#$%&'()*+,-./01
  32 33 34 35 36 37 94 7a 7e                         234567.z~
  ---------------------------------------------------------------

As shown in Figure 6.32, these packets are 169 bytes, excluding the Ethernet framing, compared to 84 bytes for a normal ping packet. All VPNs have some overhead, of course, but here we have doubled the packet size. Even in the best case of a full-size Ethernet frame, we have about 85 bytes out of 1,500 devoted to VPN overhead.

Ethernet is not the only link-layer protocol, of course, and some of the others have larger MTUs. For these protocols, the size overhead is not as onerous. Nevertheless, Ethernet is, at the time of this writing, by far the most common.

The real overhead of our tunnel is not size, however, but time. Notice that the ping times are about 2.32.4 milliseconds. Recall that these times were measured on a LAN, not on the Internet. For comparison, here is a ping between bsd and linux that does not go through the tunnel:

bsd# ping linux
PING linux.jcs.local (172.30.0.4): 56 data bytes
64 bytes from 172.30.0.4: icmp_seq=0 ttl=64 time=0.186 ms
64 bytes from 172.30.0.4: icmp_seq=1 ttl=64 time=0.214 ms
64 bytes from 172.30.0.4: icmp_seq=2 ttl=64 time=0.214 ms
64 bytes from 172.30.0.4: icmp_seq=3 ttl=64 time=0.212 ms
...

We see that the ping times in the tunnel are an order of magnitude greater than those that don't go through the tunnel. It's not difficult to understand the difference. In addition to the normal IP/ICMP processing, we have the SSL/stunnel overhead, including the expensive encryption, and the overhead of the PPP processes.

In one sense, we tested our VPN in a way that is most favorable to it. That's because the tunnel was running on a LAN (see Tip 12 of ETCP), and we weren't running TCP over it. If we had established our tunnel between two machines on the Internet and made a TCP connection between them over the tunnel, we would have seen even poorer performance: We would have been tunneling one TCP connection over another, and the retransmission strategies of the two TCPs would have interfered with each other. In general, it's not a good idea to tunnel one reliable protocol inside another, because both are trying to provide reliability, and they can get in each other's way.


Section 6.7. SSL Security

6.7. SSL Security

Ironically, most experts believe that although SSL provides an excellent secure channel with strong encryption and authentication, it does a poor job at its original purpose of protecting Web transactions. This is not a weakness of the SSL protocol itself but rather a result of the way browsers implement it. The problem is that although SSL can verify the identity of a server, the browsers do a poor job of informing their users of that identity in a way that allows them to make an informed decision about whether the connection is with the server that they intended.

Bruce Schneier's description of the problem [Schneier 2003] is typical: "Imagine you are sitting in a lightless room with a stranger. You know that your conversation cannot be eavesdropped on. What secrets are you going to tell the stranger? Nothing, because you have no idea who he is. SSL is kind of like that." Of course, we do tell that stranger our secrets. The current epidemic of so-called phishing attacks, where users are duped into connecting to a dummy site, is an example of this.

An excellent analysis of the security aspects of the SSL 3 protocol is presented in [Wagner and Schneier 1996]. Although the authors identify a few small problems, they conclude that, by and large, the protocol provides excellent security against passive attacks and, except for a couple of protocol issues that could lead to implementation errors, against active attacks as well.

Canvel, Hiltgen, Vaudenay, and Vuagnoux [Canvel, Hiltgen, Vaudenay, and Vuagnoux 2003] combined Vaudenay's attack on CBC padding [Vaudenay 2002] with a timing attack, and used it to recover passwords for an SSL-secured IMAP server. The timing attack takes advantage of the difference in time it takes the server to check for correct padding versus a correct MAC. Because most SSL servers at the time reported the error as soon as they detected it, the attacker was able to discern whether the padding was correct and thus apply Vaudenay's attack.

This attack is made possible by an implementation error, of course, and SSL servers now take pains to make sure that the timing attack won't workby always performing both tests before reporting an error, for example. Because most SSL servers default to RC4 encryption, which is not vulnerable to Vaudenay's attack, this exploit had little practical importance except to illustrate, once again, the dangers of leaking even seemingly innocuous information.


Section 6.8. Summary

6.8. Summary

In this chapter, we've taken a fairly detailed look at the SSL protocol. Although it is most often thought of as a way of securing Web transactions, SSL is, in fact, a versatile protocol with many uses. We examined the protocol, its message formats, and many of its negotiation mechanisms.

The OpenSSL library and support front end is, by far, the most common open source implementation of SSL. As we saw, one can use the library to write simple SSL-aware applications in a fairly straightforward way. Complex applications are more complicated, but the library is flexible and able to handle any reasonable demands placed on it. The OpenSSL front-end program, openssl, is very useful for performing administrative tasks, such as creating and signing certificates, as well as for handling routine encryption/decryption tasks and S/MIME mail chores.

Finally, we explored the stunnel program and saw how we can use it to connect two applications with SSL even if one or both of them are SSL-unaware. We also saw how we can use stunnel and PPP to build an SSL VPN between two networks. Although this type of VPN suffers from performance problems that limit its practicality, it's easy to set up and can be useful in certain settings.


Exercises

6.1 | Can we use RC4 with DTLS? Why or why not?
6.2 | We said that during a client certificate exchange, the client verifies that it is the certificate owner by sending the server a CertificateVerify message. How does the server prove to the client that it is the owner of the certificate that it sends?
6.3 | Set up a PPP/SSL VPN between a Linux and FreeBSD machine where the Linux machine is the client and the FreeBSD machine is the server.
6.4 | Increase the security of our PPP/SSL tunnel by adding PPP-level authentication to both sides.
6.5 | Build an SSL VPN without using PPP. Hint: Use gtunnel and stunnel.
6.6 | Write an SSL client that provides an interactive session to the user at the terminal. Test your client with our sslecho server.


Chapter 7. SSH

    Section 7.1. Introduction

    Section 7.2. The SSHv1 Protocol

    Section 7.3. The SSHv2 Protocol

    Section 7.4. Building VPNs with SSH

    Section 7.5. Summary

    Exercises


Section 7.1. Introduction

7.1. Introduction

Historically, telnet, ftp, and the BSD r-commands (rcp, rsh, rexec, and rlogin) have been used to handle interactive sessions and file transfers between a local and a remote host. Although these utilities are still popular and in widespread use, their severe security problems make them unsuitable for use in settings where security is a concern. For example, telnet and ftp provide no encryption or authentication services, so any data transferred using them is vulnerable to eavesdroppers using simple passive attacks. More seriously, these utilities send the user's password as plaintext, allowing the attacker to recover it and subsequently log on to the remote system as the user.

The r-commands are even worse. They share the same problems as telnet and ftp and are often configured to use a convenience mode that does not require the user to present any credentials. This mode is easily subverted to allow an attacker on any machine to log on to or run commands on the target machine as any user authorized to use the r-commands.

The Secure Shell (SSH) suite is a set of programs that serve as drop-in replacements for telnet, ftp, and the r-commands.

More accurately, SSH is a set of protocols. Because their most popular implementations are the UNIX programs ssh and sshd, most users think of SSH as its implementation rather than the underlying protocols.

Despite its name, SSH has nothing to do with a shell, such as sh, csh, or bash. Rather, SSH provides a secure connection over which a user may, among other things, run a remote shell session.

When we examine this connection, we will see that it meets our requirements for a VPN. Data sent, for example, over the public Internet is encrypted and authenticated, ensuring that it is safe from snooping and alteration. From the user's perspective, these VPN functions are transparent. The user need merely call ssh rather than, say, rsh to enjoy the benefits of VPN-like security.

Two versions of SSH are in use today. These are not program versions; they are protocol versions. That is, the SSH protocol has two independent versions. Fortunately, most implementations support both versions and will negotiate which version to use at session start-up time.

In 1995, Helsinki University of Technology researcher Tatu Ylönen developed the first version of SSH. As often happens, he designed it for his own use, in this case, as a response to a password-sniffing attack on his university's network. As also often happens, Ylönen released his code for others to benefit from, and its use exploded all over the world. To deal with the increasing support issues, Ylönen formed SSH Communications Security (SCS, <http://www.ssh.com>) that same year. This version of the software is now known as SSH version 1 (SSHv1).

Actually version 1 of the protocol underwent steady refinement. What is now known as SSHv1 is really version 1.5 of the protocol.

As with SSL, there were no formal design documents for the first version of SSH, but Ylönen did document the protocol after the fact as an Internet Draft (draft-ylonenssh-protocol-00.txt). This draft has long since expired, of course, but is still distributed with the SSH source code and is available in various repositories on the Web (see, for example, <http://www.watersprings.org/pub/id/index-y.html>).

Because of security problems with SSHv1, SCS released version 2 of the protocol in 1996. SSHv2 is a complete rewrite of the SSH protocol and is incompatible with SSHv1. The IETF became involved by forming the Secure Shell working group (SECSH). Their Web site is at <http://www.ietf.org/html.charters/secsh-charter.html>.

In late 1999, in response to increasingly restrictive licenses from SCS, the OpenSSH project (<http://www.openssh.com>) released an SSHv1 implementation based on SCS's 1.2.12 release. This version supported protocol versions 1.3 and 1.5. In June 2000, OpenSSH released support for SSHv2, and support for Secure FTP (SFTP) followed soon afterward in November of that year. At this time, the OpenSSH suite is the most common implementation of the SSH protocols.


Section 7.2. The SSHv1 Protocol

7.2. The SSHv1 Protocol

Like SSL, SSH is a transport-layer protocol and uses TCP to carry its packets. This has the usual advantages of providing an underlying reliable transport, freeing SSH from having to worry about retransmissions, packet ordering, and flow control. Unlike SSL, SSH does not require that either the local or remote application be SSH-aware. The situation is more analogous to an stunnel environment, such as that in Figure 6.24. That is, SSH provides a secure tunnel through which local and remote applications may communicate.

The most common case is shown in Figure 7.1: A local user is communicating with a remote shell. In this case, the ssh client is providing the local user with a terminal interface, but this is merely a convenience. This use of ssh is as a secure replacement for rsh and is virtually identical from the user's perspective.

Figure 7.1. SSH as a Remote Shell

Because the use of ssh as a replacement for rsh and telnet is so common, we first examine the SSH protocol from the point of view of the remote shell application. Later, we consider other applications and capabilities of the SSH protocols.

Let's start with a simple interactive session and watch the protocol in action as SSH connects; authenticates the server, client, and user; transfers user data securely; and finally disconnects. In order to see the unencrypted packets, we specify null encryption (-c none). As we see, ssh warns us that there will be no encryption and that the password will be passed in the clear, just as it is for, say, telnet.

Although the SSH protocol recommends that null encryption should be available for debugging purposes and although OpenSSH does provide support for it, there is no way to request it from the command line. We are using a patched version that recognizes the -c none option. Our patched server is listening on port 2022 instead of the normal port 22; that is why we specify -p 2022 on the call to ssh.

The -1 and -4 specify the version 1 protocol and IPv4, respectively.

$ ./ssh -1 -4 -c none -p 2022 guest@localhost
WARNING: Encryption is disabled! Password will be transmitted
in clear text.
guest@localhost's password:
Last login: Sat May 15 14:55:16 2004 from localhost
Have a lot of fun...
guest@linuxlt:~> ls
Documents public_html
guest@linuxlt:~> exit
logout
Connection to localhost closed.

After we supply our password, sshd starts a shell for us, and we list the home directory of user guest. Finally, we exit from the shell, and the connection is torn down.

Before studying the protocol messages for this session in detail, we must examine the SSHv1 binary protocol packet. Figure 7.2 shows the format of these packets.

Figure 7.2. The SSHv1 Binary Packet

[View full size image]

As with the SSL packets from Chapter 6, the SSH packet does not necessarily align its data on word boundaries, so we display them as we did for SSL.

The length field is the size of the packet, not including the length field itself or the variable-length random padding field that follows it. The padding field is intended to make known text attacks more difficult. Its size is chosen to make the size of the encrypted part of the packet a multiple of 8 bytes.

This is presumably because all the block ciphers originally supported by SSHv1 have a 64-bit block size. The OpenSSH version 1 protocol supports only DES, 3DES, and Blowfish, all of which use a 64-bit block size.

Following the padding is a 1-byte type field that identifies the type of message that the packet contains. The type values are shown in Figure 7.3.

Figure 7.3. SSHv1 Message Types

No.

MessageName

Message

0

SSH_MSG_NONE

never sent

1

SSH_MSG_DISCONNECT

causes immediate connection teardown

2

SSH_SMSG_PUBLIC_KEY

server's public key

3

SSH_CMSG_SESSION_KEY

client choice of cipher and session key

4

SSH_CMSG_USER

userlogon name

5

SSH_CMSG_AUTH_RHOSTS

request for user rhosts type authentication

6

SSH_CMG_AUTH_RSA

request for user RSA authentication

7

SSH_SMSG_AUTH_RSA_CHALLENGE

server challenge for RSA authentication

8

SSH_CMSG_AUTH_RESPONSE

client response to RSA challenge

9

SSH_CMSG_AUTH_PASSWORD

request for password authentication

10

SSH_CMSG_REQUEST_PTY

request for a server pseudoterminal

11

SSH_CMSG_WINDOW_SIZE

client's window size

12

SSH_CMSG_EXEC_SHELL

request to start a user shell

13

SSH_CMSG_EXEC_CMD

request to run a command

14

SSH_SMSG_SUCCESS

server accepts last request

15

SSH_SMSG_FAILURE

server does not accept last request

16

SSH_CMSG_STDIN_DATA

client input data for shell/command

17

SSH_SMSG_STDOUT_DATA

output data from shell/command

18

SSH_SMSG_STDERR_DATA

STDERR output from shell/command

19

SSH_CMSG_EOF

client is finished sending data

20

SSH_SMSG_EXITSTATUS

exit status from shell/command

21

SSH_MSG_CHANNEL_OPEN_CONFIRMATION

indicates channel opened

22

SSH_MSG_CHANNEL_OPEN_FAILURE

indicates channel could not be opened

23

SSH_MSG_CHANNEL_DATA

data transmitted over channel

24

SSH_MSG_CHANNEL_CLOSE

sender is closing channel

25

SSH_MSG_CHANNEL_CLOSE_CONFIRMATION

sender acknowledges channel close

26

obsolete

27

SSH_SMSG_X11_OPEN

client is connected to proxy X-server

28

SSH_CMSG_PORT_FORWARD_REQUEST

client requests server port be forwarded

29

SSH_MSG_PORT_OPEN

connection made on forwarded port

30

SSH_CMSG_AGENT_REQUEST_FORWARDING

requests authentication agent forwarding

31

SSH_SMSG_AGENT_OPEN

requests channel to authentication agent

32

SSH_MSG_IGNORE

no op

33

SSH_CMSG_EXIT_CONFIRMATION

response to SSH_SMSG_EXITSTATUS

34

SSH_CMSG_X11_REQUEST_FORWARDING

requests a proxy X-server

35

SSH_CMSG_AUTH_RHOSTS_RSA

requests rhosts/RSA authentication

36

SSH_MSG_DEBUG

debugging information for peer

37

SSH_CMG_REQUEST_COMPRESSION

client requests compression

The type field is followed by the message data. The CRC field, which serves as a MAC, ends the packet. When encryption is enabled, everything except the length field is encrypted.

The protocol allows for optional compression of the data. This can be useful when SSH is used in low-bandwidth situations such as dial-up lines. If the client and server negotiate compression, only the type and data fields are compressed.

Many of these messages either carry no argumentsthey consist of only the length, padding, type, and CRC fieldsor have a single argument consisting of a string, integer, or extended integer. In these cases, we won't bother showing the message layout but will merely indicate what type of argument, if any, the message carries.

Server Authentication

The server authentication phase of the session, as shown in Figure 7.4, begins with the exchange of identification strings. When the SSH client, ssh, connects to the SSH server, sshd, the server sends an identification string indicating which of the protocols it supports and, perhaps, additional program version information. For example, if we connect to the SSH server with netcat, the server responds with its identification string:

$ nc linux 22
SSH-1.99-OpenSSH_3.5p1

Figure 7.4. SSHv1 Server Authentication

The SSH-1.99 is a special version number that tells the client that the server supports protocol versions 1 and 2. The -OpenSSH_3.5p1 is meant for human consumption and specifies the version of the OpenSSH SSH server. The client will respond with its own identification string, so that the peers will know which protocol to use.

After the server receives the client's identification string, the peers switch to the binary protocol, and the server sends the SSH_SMSG_PUBLIC_KEY message shown in Figure 7.5.

Figure 7.5. SSH_SMSG_PUBLIC_KEY Message

[View full size image]

The cookie is 8 random bytes that are intended to make IP spoofing more difficult. The client must return these bytes to the server unchanged.

The host key is a permanent RSA public key that the client uses to verify the identity of the server. Unlike with SSL, this key is not signed by a third party. Rather, the client is expected to have a database of known host keys. In practice, this database is built by accepting the key as valid the first time a user connects to a host. Thereafter, the host must present the known key to the client for the session to proceed. SSH also supports a key-fingerprinting mechanism that allows a user to manually verify a site's key with the site's system administrator. There is also a proposal to make these fingerprints available through DNS by means of SSHFP (SSH key fingerprint) records.

The server also sends a second key, the server key. This key is regenerated periodically, once every hour by default, to help improve security. As we shall see, the client uses both of these keys to form its response to the server.

Finally, the message includes three 32-bit bit masks. The protocol flags bit mask is intended for protocol extension. The supported ciphers mask indicates which ciphers the server can use. The client will choose one of these for the session's cipher. The supported authentications mask indicates which user authentications the server supports. Again, the client will try one or more of these methods to authenticate the user.

Both sides use the information in this message to calculate a session ID by taking the MD5 hash of the concatenation of the moduli of the server and host keys and the cookie. As we'll see, the session ID is used in generating the session key and thus ensures that both the client and server contribute to the session key.

From Figure 7.4, we see that the client responds to the SSH_SMSG_PUBLIC_KEY message with an SSH_CMSG_SESSION_KEY message, shown in Figure 7.6.

Figure 7.6. SSH_CMSG_SESSION_KEY Message

[View full size image]

The cipher type field contains the number of the cipher that the client has chosen for the session. The cookie and protocol flags fields are just as they were for the SSH_SMSG_PUBLIC_KEY message. In particular, the cookie must be returned to the server exactly as it was received by the client.

The encrypted session key field is a random 32-byte value chosen by the client. The session ID, calculated from the values in the SSH_SMSG_PUBLIC_KEY message, is exclusive-ORed into the first 16 bytes of the random value. This result is then encrypted twice: first by the smaller (usually the server) RSA key and then by the other (usually host) key.

Although this operation seems complicated, it accomplishes three separate tasks. First, by exclusive-ORing the session ID into the random value used for the session key, the client ensures that both the server and the client contribute to the final session key. Then, by encrypting with the host key, the client verifies the identity of the server, because the server must have the corresponding private key in order to recover the session key. Finally, by encrypting with the server key, the client ensures perfect forward secrecy by using the periodically changing server key.

Both sides now begin encrypting their packets. The server completes the server authentication phase by sending an SSH_SMSG_SUCCESS message. At this point, the peers have established a secure channel, and the server has authenticated itself to the client.

User Authentication

The next step is for the user to authenticate himself to the server. This can be done in several ways. SSH allows, but discourages, the insecure rhosts trusted-host model. Because it is easily spoofed, this model should never be used when security is important. SSH also supports a variation of the rhosts model in which the identity of the client machine is verified with an RSA key. This is an improvement but still relies on the client to certify the identity of the user. Once again, this method should not be used when security or user identity is a concern. The rhosts and rhosts/RSA methods are discussed in detail in [Barrett and Silverman 2002], so we will not belabor them further here.

A third authentication method is to use Kerberos. With this method the user obtains a "ticket" from the Kerberos server and sends it to the SSH server as authentication. Although Kerberos is a complicated system and requires a separate server, it may make sense when there is a large user base, especially if Kerberos is already in place. See [Garman 2003] for more information on Kerberos.

Next, there is a class of methods known as password authentication. In the simplest of these, which we'll examine shortly, the user merely supplies a password, which the server checks against its password file. Recall that after server authentication, the peers have established a secure channel, so this password is not passed in the clear as it is in, say, the telnet protocol.

The other password methods are variations of a one-time-password scheme. One example is the popular RSA SecurID system, which is described at RSA's Web site (<http://www.rsasecurity.com/node.asp?id=1156>). With SecurID, the user carries a hardware device, such as a key fob, that generates a pseudorandom number every 60 seconds. During authentication, the user enters the pseudorandom number and a private PIN. If the correct values are entered, the user is authenticated, and the session is started.

Another one-time-password scheme is the S/Key system [Haller 1994, Haller 1995], a challenge/response system. With S/Key, the user is prompted with a challenge and responds with a set of short words. This response can be obtained either programmaticallyfrom a PDA applet, sayor from a preprinted list. As with SecureID, passwords are not reused, thereby increasing security. The S/Key system is supported by OpenSSH.

Each of these password methods has its own protocol, but they all depend on the SSH secure channel for their security. The enhanced methods, such as SecureID and S/Key, derive their increased security from the fact that they use one-time passwords and are thus resistant to local passive attacks, such as keyboard loggers and other attempts to capture the password before it enters the encrypted channel; even if a password is captured, it is useless because it's not reused.

Figure 7.7 shows the protocol for a simple password-based user authentication.

Figure 7.7. User Authentication with a Password

First, the client sends the server the user's name as a string in the SSH_CMSG_USER message. If no further authentication is requiredrhosts authentication is being used, for examplethe server will respond with an SSH_SMSG_SUCCESS message, and authentication will be completed. If further credentials, such as a password, are required, the server will respond with an SSH_SMSG_FAILURE message, indicating that the user name alone is not sufficient. SSH_SMSG_SUCCESS and SSH_SMSG_FAILURE are both simple messages with no arguments.

At this point, the client will try various authentication methods until it finds one acceptable to the server. In our example session, the client first tries a standard password authentication by sending the server an SSH_CMSG_AUTH_PASSWORD message containing the user's password as a string. In our case, this is acceptable, and the server returns an SSH_SMSG_SUCCESS message indicating that the authentication is complete.

Because SSHv1 normally encrypts everything in its messages except the length, there is not much sense in dwelling on packet captures as a debugging aid. Nevertheless, it is instructive to see what the messages look like, to aid us in understanding the protocol. Therefore, let's briefly examine the messages from Figure 7.7 in detail.

We begin with the SSH_CMSG_USER message from the client. As we see from bytes 58 in line 1.4, the message is 14 bytes long. From line 1, we see that the TCP segment is 20 bytes long, so there are 20 - 14 - 4 = 2 bytes of padding. The padding is easy to spot because OpenSSH pads with zero bytes.

Next, we see the message type (0x04) in byte 11 of line 1.4. From Figure 7.3, we see that this is indeed the SSH_CMSG_USER message. Following the message type is the user's logon name, guest in this case. In SSH, string data is preceded by 4 bytes of length followed by the string data. There is no trailing NULL byte. Finally, the last 4 bytes are the CRC, which serves as a MAC.

In line 2, the server responds with its SSH_SMSG_FAILURE message. The message type (0x0f) is on line 2.4. Line 3 is the TCP ACK for the segment in line 2. This occurs because of the time it takes to type in the password.

1   14:56:52.381285 127.0.0.1.32802 > 127.0.0.1.2022: P 184:204(20)
     ack 316 win 3276 7 <nop,nop,timestamp 468782 468782> (DF)
1.1    4500 0048 0daa 4000 4006 2f04 7f00 0001    E..H..@.@./.....
1.2    7f00 0001 8022 07e6 2b99 26b8 2b24 4d08    ....."..+.&.+$M.
1.3    8018 7fff d4cb 0000 0101 080a 0007 272e    ..............'.
1.4    0007 272e 0000 000e 0000 0400 0000 0567    ..'............g
1.5    7565 7374 33b3 5ce1                        uest3..
2   14:56:52.381867 127.0.0.1.2022 > 127.0.0.1.32802: P 316:328(12)
     ack 204 win 3276 7 <nop,nop,timestamp 468782 468782> (DF)
2.1    4500 0040 0dab 4000 4006 2f0b 7f00 0001    E..@..@.@./.....
2.2    7f00 0001 07e6 8022 2b24 4d08 2b99 26cc    ......."+$M.+.&.
2.3    8018 7fff a93e 0000 0101 080a 0007 272e    .....>........'.
2.4    0007 272e 0000 0005 0000 000f 90bf 1d91    ..'.............
3   14:56:52.413821 127.0.0.1.32802 > 127.0.0.1.2022:  . ack 328
      win 32767 <nop,nop,timestamp 468786 468782> (DF)

Next, we see the SSH_CMSG_AUTH_PASSWORD message (type 0x09) carrying the password of knockknock. Because this password is acceptable to the server, it responds with a SSH_SMSG_SUCCESS message in line 5. As we see in line 5.4, the SSH_SMG_SUCCESS message carries no data other than its message type (0x0e).

4   14:56:59.534978 127.0.0.1.32802 > 127.0.0.1.2022: P 204:256(52)
           ack 328 win 3276 7 <nop,nop,timestamp 469498 468782> (DF)
4.1    4500 0068 0dba 4000 4006 2ed4 7f00 0001     E..h..@.@.......
4.2    7f00 0001 8022 07e6 2b99 26cc 2b24 4d14     ....."..+.&.+$M.
4.3    8018 7fff ecd7 0000 0101 080a 0007 29fa     ..............).
4.4    0007 272e 0000 0029 0000 0000 0000 0009     ..'....)........
4.5    0000 0020 6b6e 6f63 6b6b 6e6f 636b 0000     ....knockknock..
4.6    0000 0000 0000 0000 0000 0000 0000 0000     ................
4.7    0000 0000 7ba8 d3b8                         ....{...
5   14:56:59.536726 127.0.0.1.2022 > 127.0.0.1.32802: P 328:340(12)
            ack 256 win 3276 7 <nop,nop,timestamp 469498 469498> (DF)
5.1    4500 0040 0dbc 4000 4006 2efa 7f00 0001     E..@..@.@.......
5.2    7f00 0001 07e6 8022 2b24 4d14 2b99 2700     ......."+$M.+.'.
5.3    8018 7fff 3cf8 0000 0101 080a 0007 29fa     ....<.........).
5.4    0007 29fa 0000 0005 0000 000e e7b8 2d07     ..)...........-.

The final type of user authentication, RSA authentication, uses RSA keys as certificates. The public key is placed in the user's home directory on the server, usually in the .ssh subdirectory. Similarly, the private key is kept in the user's home directory on the client. If the client has an RSA key available, it will query the server as to whether it has the corresponding public key. It does this by sending the key's modulus in an SSH_CMSG_AUTH_RSA message. The entire RSA authentication process is shown in Figure 7.8.

Figure 7.8. SSHv1 RSA Authentication

The exchange starts with the client sending the usual SSH_CMSG_USER message with the user's logon name. The server responds with the SSH_SMSG_FAILURE message, indicating that further authentication is required. So far, this is the same as for password authentication, but with RSA authentication instead of the client sending the SSH_CMSG_AUTH_PASSWORD message, it sends an SSH_CMSG_AUTH_RSA message containing the modulus of the RSA key as an extended integer. The server checks in the user's home directory for a public key with the same modulus. If it finds one, the server uses it to encrypt a random 256-bit challenge, which it sends to the client in an SSH_SMSG_AUTH_RSA_CHALLENGE message. The challenge is carried as an extended integer. The client decrypts the challenge with its private key, combines it with the session ID, and takes an MD5 hash of the result. The hash is sent to the server in an SSH_CMSG_AUTH_RESPONSE message as 16 bytes of untyped data. The server takes its own MD5 hash of the challenge and session ID and compares it with the one it received from the client. If they match, the server sends the client an SSH_SMSG_SUCCESS message, indicating that the authentication succeeded. If the results don't match, the server will respond with an SSH_SMSG_FAILURE message, informing the client that it should try another form of user authentication.

Once user authentication is completed, SSH is ready to begin a user application. By default, this means that SSH will start a user shell on the server and transport the shell's standard input, output, and error over the encrypted channel. We show this for the case of our sample session in Figure 7.9.

Figure 7.9. Starting a User Shell

First, the client requests the server to start a pseudo-tty session for it with the SSH_CMSG_REQUEST_PTY message. This message contains the terminal type and characteristics of the user's session, as shown in Figure 7.10. After the server acknowledges the request with an SSH_SMSG_SUCCESS message, the client requests the server to start a shell and connect it to the pseudo-tty with an SSH_CMSG_EXEC_SHELL message. The client and server then exchange data with the SSH_CMSG_STDIN_DATA and SSH_SMSG_STDOUT_DATA messages. The SSH_CMSG_EXEC_SHELL message contains no arguments. The arguments for the SSH_CMSG_STDIN_DATA and SSH_SMSG_STDOUT_DATA messages are carried as string data.

Figure 7.10. The SSH_CMSG_REQUEST_PTY Message

When we typed exit, the shell sent a final "logout" message and terminated. That caused SSH to tear down the encrypted channel, as shown in Figure 7.11.

Figure 7.11. Channel Teardown

First, the server sent an SSH_SMSG_EXITSTATUS message containing the exit status of the shell. If the shell had been terminated by a signal, the server would have sent an SSH_MSG_DISCONNECT message containing a human-readable string indicating the cause of the termination. The client confirms the shell termination by responding with a SSH_CMSG_EXIT_CONFIRMATION message, which contains no arguments. These two messages are the last messages sent by the server and the client, respectively.

X11 Forwarding

Both versions of SSH can forward an X11 connection from an X-client on the SSH server to an X-server on the SSH client. This works by having the SSH server listen for connections to the X-server from localto the serverX-clients, in effect establishing an X11-server proxy. The SSH server then forwards the X-protocol messages from the X-client over an encrypted channel to the SSH client, which in turn forwards them to the real X-server on the SSH client side. Similarly, X-protocol messages from the X-server on the client are transferred over the encrypted channel to the X-client on the SSH server. In Figure 7.12, an X-client on the server host connects to the X-server proxy and has its X-protocol messages delivered over the SSH encrypted channel to the X-client proxy on the client host. The X-client proxy in turn connects to the real X-server and forwards messages from the X-client to it. Although both the X-client and X-server believe themselves to be directly connected to their peer and that their peer is on the same machine, the actual connection follows the shaded path shown in Figure 7.12.

Figure 7.12. A Forwarded X11 Connection

[View full size image]

If the SSH client wishes to enable X11 forwarding, it sends the SSH server an SSH_CMSG_X11_REQUEST_FORWARDING message after completing the user authentication phase. This message will cause the server to arrange for local X-clients to connect to a socket on which it is listening.

The server does this by pointing the environment's DISPLAY variable at a socket on which it listens for connections. For example, if we ssh into linuxlt from bsd, specifying X11 forwarding, and echo the DISPLAY variable, we get

echo $DISPLAY
localhost:10.0

This corresponds to listening on the loopback interface at port 6010. If we echo the DISPLAY variable from the console of linuxlt, we get

echo $DISPLAY
:0

which corresponds to listening on all interfaces at port 6000. We can verify this by running netstat -naAinet on linuxlt. The relevant entries, after some reformatting, are as expected:

Proto   Local Address    Foreign Address   State
tcp     0.0.0.0:6000     0.0.0.0:*         LISTEN
tcp     127.0.0.1:6010   0.0.0.0:*         LISTEN

The SSH_CMSG_X11_REQUEST_FORWARDING message is shown in Figure 7.13.

Figure 7.13. The SSH_CMSG_X11_REQUEST_FORWARDING Message

[View full size image]

The authentication protocol and authentication data fields contain data that the proxy X-server can use to authenticate X-clients on the SSH server. See [Barrett and Silverman 2002] for details on X11 authentication and authentication spoofing. The screen number field specifies the screen number to use. This field is present only if the SSH_PROTOFLAG_SCREEN_NUMBER bit is set in the protocol flags field of the client's SSH_CMSG_SESSION_KEY message.

When an X-client connects to the proxy X-server, the SSH server sends an SSH_SMSG_X11_OPEN message to the SSH client. This message contains a 32-bit integer field specifying the channel number that it will use for the connection and an optionalif both sides set the SSH_PROTOFLAG_HOST_IN_FWD_OPEN bit in their protocol flag fields during key exchangestring containing a description of the host opening the X11 connection.

The client responds by trying to connect to the real X11 server and sending an SSH_MSG_CHANNEL_OPEN_CONFIRMATION if the connection to the X-server succeeded or an SSH_MSG_CHANNEL_OPEN_FAILURE message if the connection failed.

The SSH_MSG_CHANNEL_OPEN_CONFIRMATION message, shown in Figure 7.14, contains two 32-bit integers. The remote channel field is the peer's identifier for the channel over which the X-protocol will be sent. It is the value contained in the SSH_SMSG_X11_OPEN message. The local channel field is the SSH client's identifier for the secure channel.

Figure 7.14. The SSH_MSG_CHANNEL_OPEN_CONFIRMATION Message

[View full size image]

This is reminiscent of L2TP, in which each of the peers had its own identifier for a data channel.

The SSH_MSG_CHANNEL_OPEN_FAILURE message contains a single 32-bit integer that is the peer's identifier for the channel. In the context of X11 forwarding, this message means that the SSH client was unable to connect to the local X-server.

Once the client sends the SSH_MSG_CHANNEL_OPEN_CONFIRMATION, a secure, bidirectional data channel is available to the peers. As noted previously, the SSH server will use it to forward X-protocol messages from a local X-client, and the SSH client will use it to forward X-protocol messages from the X-server back to the X-client on the SSH server. The peers use the SSH_MSG_CHANNEL_DATA message, shown in Figure 7.15, to carry the channel data. The remote channel field is a 32-bit integer containing the peer's identifier for the channel. The data is carried as a string in the data field.

Figure 7.15. The SSH_MSG_CHANNEL_DATA Message

[View full size image]

Either side of the X11 connection may close it by sending the SSH_MSG_CHANNEL_CLOSE message, which contains the peer's value for the channel number as an integer. For example, the SSH server will send this message when the X-client disconnects from the X-proxy server. The other side will let any queued data drain from the connection and will then send an SSH_MSG_CHANNEL_CLOSE_CONFIRMATION message to complete the channel teardown. Figure 7.16 shows the SSH protocol exchange in a typical forwarded X11 session.

Figure 7.16. Forwarded X11 Connection Flow

Port Forwarding

In the previous subsection, we examined SSH X11 forwarding. Both SSH versions also have a more general connection forwarding capability called port forwarding. This capability is much like that provided by stunnel. The most general case is shown in Figure 7.17: host A wants to connect securely to port R on host B. Instead of directly connectingpossibly across the Internet or other insecure pathto host B, host A connects to port L on the SSH client host instead. SSH then forwards this connection through a secure channel to the SSH server that connects to port R on host B. Thereafter, data from host A travels to the SSH client on the local connection, across the SSH tunnel, and finally across the local connection that the SSH server made to host B. Host B is unaware that forwarding is going on and merely listens for connections on port R as usual. Host A connects to the SSH client, which is listening on port L, instead of to host B.

Figure 7.17. SSH Local Port Forwarding

[View full size image]

For security reasons, the default behavior of the SSH client is to listen for local connections only from applications on the same machine. A special flag to ssh is required to get the behavior shown in Figure 7.17. Often the remote application will be on the same machine as the SSH server, but the protocol makes no assumptions about this.

It is also possible to have remote applications connect back to the SSH client host or to a host reachable by the SSH client, as shown in Figure 7.18.

Figure 7.18. SSH Remote Port Forwarding

[View full size image]

In this case, host B wants to connect to host A on port L. When the SSH client requests remote port forwarding, the SSH server listens for connections on the specified port: say, port R. When an application connects to port R, the connection is forwarded through the SSH tunnel to the SSH client, which then connects to port L on the target host: host A in Figure 7.18.

As we mentioned in Chapter 5 during our discussion of L2TP/IPsec, it is important to understand the end-to-end security of the tunnels that we set up. For example, if the client application and server application that we port forward between are on the same machines as the SSH client and server, the entire path between application and corresponding server is protected. If, on the other hand, we have a situation such as that in Figure 7.17 or Figure 7.18, parts of the path are unprotected. This may or may not be a problem. If, for instance, host A of Figure 7.17 is on the same trusted network as the SSH client machine, the fact that the connection between host A and the SSH client is not secured may be okay. The same configuration may not be okay if the connection between host A and the SSH client machine is exposed to untrusted parties. Thus, it is important to understand both the threat model and the security of each leg of a proposed VPN.

Let's look at the SSH protocol messages involved in forwarding a local port. We assume that the user has requested SSH to forward port L on the SSH client to port R on a remote server reachable by the SSH server and that the server is the first to disconnect, initiating the channel teardown. Figure 7.19 shows the SSH message flow.

Figure 7.19. Port Forwarding Protocol Exchange

The process begins when an application connects to port L on the SSH client host. The SSH client responds to the connection by sending the SSH server an SSH_MSG_PORT_OPEN message indicating that a connection has been made to a port for which the user requested forwarding and asking the server to connect to the specified host and port. The SSH_MSG_PORT_OPEN message is shown in Figure 7.20. The local channel field is the client's identification number for the channel. The SSH server will use this channel number when sending data to or about this connection to the client.

Figure 7.20. The SSH_MSG_PORT_OPEN Message

The host name is the name or address of the host that the SSH server should connect to. Similarly, the port field is the port to which it should connect.

After connecting to the specified host, the SSH server sends an SSH_MSG_CHANNEL_OPEN_CONFIRMATION message. If it can't connect to the remote host, the SSH server will send an SSH_MSG_CHANNEL_OPEN_FAILURE message instead. Assuming that the connection succeeds, the two (non-SSH) peers can start exchanging data, which is carried in SSH_MSG_CHANNEL_DATA messages, just as in X11 forwarding.

If the remote host disconnects from the SSH server, as shown in Figure 7.19, the SSH server will send an SSH_MSG_CHANNEL_CLOSE message, and the SSH client will respond with an SSH_MSG_CHANNEL_CLOSE_CONFIRMATION message after shutting down its end of the connection. If the local host disconnects first, the actions are the same except that the SSH client sends the SSH_MSG_CHANNEL_CLOSE, and the SSH server responds.

The protocol exchange for remote port forwarding is the same except that the SSH client must first tell the SSH server to start listening on a portport R, sayfor a connection from the remote host. This is accomplished by having the SSH client send an SSH_CMSG_PORT_FORWARD_REQUEST message, shown in Figure 7.21, right after user authentication. The server port field is the port on which the server is to listenport R in our example. The host name and port fields are the name or address and port to which the connection should be forwarded. These are the values that will be sent in the host name and port fields of the SSH_MSG_PORT_OPEN message when the remote host connects.

Figure 7.21. The SSH_CMSG_PORT_FORWARD_REQUEST Message

Running Remote Programs Through an SSH Tunnel

As mentioned previously, the most common use of SSH is to run a shell on a remote host. We can, however, ask SSH to start any program we please on the remote host and send its STDIN, STDOUT, and STDERR through the SSH tunnel.

Suppose, for example, that we want to run our echoit program on bsd securely from linuxlt:

$ ssh -t bsd echoit
Hello, world!
Hello, world!
^D                                    send an EOF to echoit
Connection to bsd closed.

The -t tells SSH to start a pseudo-tty for us. Because we are dealing with the remote program interactively through a terminal session, we need the pseudo-tty to handle terminal control characters and similar events for us.

Note that we don't get the usual login banner or shell prompt. That's because the SSH server executes our program directly, rather than starting a shell and letting us execute it from the shell.

Actually, even here the shell is involved. The SSH server executes the command by calling the shell with the -c switch. That is, the SSH server runs our command as

/usr/local/bin/bash -c echoit

where the /usr/local/bin/bash was obtained from the SHELL environment variable on bsd.

Also note that when we send echoit an EOF, its termination causes the SSH connection to be torn down just as if we had logged out of a shell connection.

From a protocol standpoint, running a remote program instead of a shell uses the same exchange of protocol messages that we saw in Figure 7.9, except that the SSH_CMSG_EXEC_SHELL message is replaced by an SSH_CMSG_EXEC_CMD message that contains the command to be run as a string.

The Secure Copy Program (SCP)

Using SSH to execute a trivial program, such as echoit, isn't very exciting, of course, and it doesn't begin to illustrate the power of the capability. When Tatu Ylönen wrote SSH, he intended it to replace the rcp routine, which copies files between local and remote hosts, as well as rsh and the other r-commands. To this end, he wrote a separate program, scp, to replace rcp.

The scp program is really just a patched version of rcp that sends it data through an SSH tunnel.

To understand how this works, let's suppose that we have two UNIX hosts: a local host, LH, and a remote host, RH. An instance of the SSH server, sshd, is listening for connections on the remote host, but otherwise no programs relevant to our discussion are running. On the local host, a user wishing to transfer the file main.c to the remote host invokes scp as

scp main.c RH:

To transfer the file securely, scp needs two things:

  1. A secure tunnel between the local and remote hosts to send the data through

  2. Another copy of scp running on the remote host to accept and store the file

The scp program can arrange for both of these things by spawning, via fork and exec, an instance of the SSH client as a child process and requesting it to execute a remote instance of scp. With OpenSSH, scp would invoke ssh as

ssh -x -oForwardAgent no -oClearAllForwardings yes RH scp -t main.c

The flags to ssh disable X11, port, and agent forwarding because this invocation of SSH will be used only to transfer the file.

See [Barrett and Silverman 2002] for information about agent forwarding.

Notice that ssh is asked to execute the following command on the remote host:

scp -t main.c

The -t flag tells the remote scp instance that it will be receiving a file, which it should store as main.c.

The flags to scp vary, depending on whether a single file is being transferred to or from the remote host or whether one or more files are being transferred to a directory on the remote host.

The four processes involved are shown in Figure 7.22. The dashed boxes represent child processes. The arrows between the scp and SSH instances represent pipes that connect the parent process to the STDIN, STDOUT, and STDERR of the child process.

Figure 7.22. An scp Connection

At this point, the two scp instances are connected through the SSH tunnel, and they perform the normal rcp protocol exchange to transfer the file. The important point here is that SSH has no special support for file transfers; it merely executes a remote application in the normal manner. Other distributed applications can be implemented in the same way.

As an example of how easy it is to implement secure distributed applications in this way, let's imagine that we have our mail delivered to a central serverRH, saythat for security reasons is reachable only by SSH. We want to know when new email has arrived without having to ssh onto the server to check. We can do this with a set of python programs: rbiff and rbiffd. We start rbiff on our local workstation and it periodically invokes rbiffd on the server to check for mail.

Figure 7.23 shows the rbiff program.

Figure 7.23. The rbiff Application

[View full size image]

23 | These lines import two modules that provide an interface to the system commands and time routines. We need these modules for the popen and sleep functions.
45 | The notify function is called to provide notification when new mail arrives. For simplicity, we show it as just printing "New Mail," but an actual application would pop up a dialog box or change an icon.
6 | This is the event loop of the application. Every 10 minutes (see line 13), this loop checks for mail on the server.
7 | This is the only part of the two programs that is aware of or deals with SSH. We open a pipe to an instance of ssh that executes rbiffd on the server RH.
813 | We read from the pipe, looking for a line that begins with "New." If we find one, we call notify to alert the user. When we get an EOF from the pipe, we close the pipe and sleep for 10 minutes.
 | The rbiffd (Figure 7.24) program has no knowledge of SSH. When invoked, the program merely checks the mailbox and writes its finding to STDOUT. We could run it directly from the command line without any change at all.

Figure 7.24. The rbiffd Application

[View full size image]

23 | We import the os module so that we can get the location of the user's mailbox from the environment.
47 | We call the newmail function, not shown, to check whether new mail is in the user's mailbox. If so, "New Mail" is output to STDOUT. Otherwise, "No New Mail" is output.
 | We've omitted the newmail function to avoid getting bogged down in the minutia of checking for new mail, but the process involves merely checking the times that the mailbox was last written to and accessed.

Security Issues with SSHv1

As with any other program, attackers and security researchers have discovered bugs, such as potential buffer overflows, in the various implementations of SSHv1 that lead to exploits. These bugs were, of course, fixed as they were discovered, so they aren't a concern to us except, perhaps, as a cautionary tale on how difficult it is to implement softwareespecially security softwarein a robust and secure manner. On the other hand, we do need to be concerned with bugs in the protocol itself. These bugs are more difficult to deal with because fixing them requires fixing the protocol rather than merely patching a particular implementation.

One example of such a vulnerability is the session key recovery exploit based on Bleichenbacher's attack on RSA messages encoded with PKCS #1 v1.5 [Bleichenbacher 1998]. This exploit is a result of problems within the SSHv1 protocol, not of any particular implementation of the protocol. The basic idea is that the attacker captures the SSH_CMSG_SESSION_KEY message and then uses a combination of a timing attack and Bleichenbacher's attack to decode the SSH_CMSG_SESSION_KEY message and recover the session key. Once the session key is known, of course, the entire (captured) message stream can be read with ease.

Bleichenbacher's attack is an adaptive procedure that sends the SSH server carefully chosen ciphertext messages and observes the behavior of the server. From these observations, the attacker is able to repeatedly narrow the interval that the session key lies in. The attack, which is described in some detail in [Waissbein and Friedman 2001], takes about 220 + 219 messages to the server. Because the server key expires every hour, the attacker must make about 400 connections per second to the server.

Many servers can't support that rate of connection, and others, such as OpenSSH, limit the number of concurrent unauthenticated connections, so not all servers are vulnerable. Note, however, that this invulnerability is serendipitous, not the result of these implementations being better coded than those that are vulnerable. The problem here is that the SSHv1 protocol causes SSHv1 servers to leak information and thus act as "oracles" for the Bleichenbacher attack.

Fortunately, vulnerable servers can be patched to prevent this exploit by regenerating the server key when they detect the attack. The longer-term solution was to change the PKCS #1 encoding scheme to make it resistant to this type of attack. See [Bleichenbacher, Kalisky, and Staddon 1998] for a description of Bleichenbacher's attack and the changes made to PKCS #1 to prevent it.

Another, more serious, problem with the SSHv1 protocol was not so easily fixed and resulted in the abandonment of SSHv1 and the development of SSHv2. Recall that SSHv1 uses a CRC instead of a MAC. Although quite good at detecting random errors introduced into a file, CRCs make weak MACs. A MAC based on a cryptographic hash, such as MD5 or SHA-1, acts as a pseudorandom function.

These functions aren't truly random, of course, because they are deterministic. The point is that the output appears not to depend on the input in any predictable way. In particular, pseudorandomness requires that given part of the output of the function but not the input, it is infeasible to determine the rest of the output.

Put another way, it's extremely difficult to construct a message m having a particular hash. CRCs, on the other hand, have relatively simple mathematical properties that make it easier to construct a message m with a given CRC value.

An exploit based on the weakness of CRC-32 as a MAC allows the insertion of arbitrary data into an SSHv1 message stream. That is, the attacker is able to insert text into the encrypted message stream, which then decrypts to text of the attacker's choice. This means, among other things, that an attacker can execute arbitrary commands on the SSH server or can display arbitrary data on the client's screen. The details of the attack are given in [Futoransky, Kargieman, and Pacetti 1998].

This exploit was much more difficult to fix than the Bleichenbacher attack. SSHv1 servers were patched with the so-called CRC-32 compensation attack detector, but this merely made the attack more difficult, not impossible. At this time, most security experts recommend against using SSHv1 in any environment where active attacks are a serious concern.


Section 7.3. The SSHv2 Protocol

7.3. The SSHv2 Protocol

In this section, we explore the version 2 SSH protocol. SSHv2 adds features and deals with security problems in SSHv1, but the design is considerably different and more flexible.

At the time of this writing, SSHv2 is still in the RFC draft stage, so in one sense the protocol is not completely defined. On the other hand, SSHv2 is widely deployed by several vendors, so few substantive changes are likely to the base protocol as it now exists. The latest draft documents are available from the IETF SECSH working group at its Web site.

From an architectural standpoint, SSHv2 replaces the monolithic protocol of SSHv1 with a layered set of protocols, as shown in Figure 7.25. The SSHv2 transport protocol uses TCP to carry its messages. The SSHv2 authentication and connection protocols, in turn, use the SSHv2 transport protocol to carry their messages. We will look at each of these protocols in detail.

Figure 7.25. The SSHv2 Protocols Layered on the TCP/IP Stack

The SSHv2 Transport Protocol

The SSHv2 transport protocol provides a reliable, secure, full-duplex data stream between the SSH peers. Secure means that the data is encrypted and has strong integrity checking in place. Full duplex means that there is an independent data stream in each direction, so both sides can transmit data independently.

In addition to providing a secure data stream, the transport protocol is responsible for authenticating the server to the client; for negotiating the encryption, integrity, and compression methods; and for the initial and subsequent key exchanges. These methods can be negotiated independently for each side. Thus, each peer can choose its own encryption, integrity, and compression methods from the set supported by its peer.

The currently supported encryption methods are 3des-cbc; blowfish-cbc; 128, 192, and 256-bit twofish-cbc; 128, 192, and 256-bit aes-cbc; 128, 192, and 256-bit serpent-cbc; idea-cbc; 128-bit cast-cbc; and RC4. The only required method is 3des-cbc. The 128-bit aes-cbc method is recommended, and the others are optional. Notice that all the block ciphers operate in cipher block chaining mode.

The draft RFC on the SSHv2 transport protocol defines four possible MAC methods: SHA-1 HMAC, SHA-1 HMAC-96, MD5 HMAC, and MD5 HMAC-96. The SHA-1 HMAC-96 and MD5 HMAC-96 methods merely use the first 96 bits of the corresponding HMAC output. See Chapter 12 for more on SHA-1 HMAC-96 and MD5 HMAC-96. Only SHA-1 HMAC is required. SHA-1 HMAC-96 is recommended, and the MD5 methods are optional. Regardless of the method chosen, the MAC is calculated by

MAC = M(key, sequence number || m)

where M is the MAC method, key is computed from a shared secret, m is the unencrypted message, and sequence number is a 4-byte unsigned integer that has an initial value of 0 and is incremented by 1 after each packet is sent. The sequence number field is implicitit is never sent. The message, m, includes the length, type, and payload.

Currently, the only compression method defined is ZLIB. This is the same compression used in SSHv1, and as in SSHv1, it may be indicated when SSH is used over low-bandwidth connections.

As we'll see when we examine algorithm negotiation, the encryption, integrity, and compression methods are identified by symbolic names. This makes it easy to add new algorithms without changing the protocol itself. In addition, the naming conventions make it possible for individual users or groups to define their own algorithms and name them without fear of a naming collision.

Before discussing the SSHv2 transport protocol in detail, we need to understand the binary packet protocol that it uses. The packet layout is slightly different from the SSHv1 binary packet layout in Figure 7.2. The SSHv2 binary packet layout is shown in Figure 7.26.

Figure 7.26. The SSHv2 Binary Packet

[View full size image]

The length field is the length of the entire packet, with the exception of the length and MAC fields. Similarly, the pad len field is the length of the padding field that follows the payload data.

The data field is the payload: the SSHv2 message that the transport layer is carrying. This message can be from any of the layers. The data field is length - pad len - 1 bytes long. As with the SSHv1 binary packet protocol, each message begins with a 1-byte message type. The message types used by the transport protocol are shown in Figure 7.27. In addition, message numbers 3049 are reserved for key-exchange packets. We will encounter these message types when we examine the key exchange protocols.

Figure 7.27. SSHv2 Transport Message Types

No.

MessageName

Message

1

SSH_MSG_DISCONNECT

terminate the connection

2

SSH_MSG_IGNORE

no op

3

SSH_MSG_UNIMPLEMENTED

message type not implemented

4

SSH_MSG_DEBUG

message contains debugging information

5

SSH_MSG_SERVICE_REQUEST

client service request

6

SSH_MSG_SERVICE_ACCEPT

server accepts service request

20

SSH_MSG_KEXINIT

algorithm negotiation

21

SSH_MSG_NEWKEYS

begin using new encryption keys

Immediately following the data is the padding field, which consists of pad len bytes of random data such that the length of the packet minus the MAC is a multiple of the cipher block size or 8, whichever is larger. The amount of padding must be between 4 and 255 bytes inclusive.

As discussed previously, the MAC field provides strong data integrity. Its length depends on the MAC method in use.

As we see from the figure, the entire packet, with the exception of the MAC, is encrypted. Note that this is different from the SSHv1 binary protocol, in which the CRC but not the length was encrypted.

Algorithm Negotiation and Key Exchange

The first step in establishing the transport layer's secure data stream is for the peers to agree on the encryption, integrity, and compression algorithms to use and to agree on the keys and IVs for the encryption and integrity algorithms. Figure 7.28 shows the protocol flow for this step. The process begins with the exchange of SSH_MSG_KEXINIT messages that list the methods that each peer can support and which methods each peer prefers. After each side receives its peer's SSH_MSG_KEXINIT message, the peers will either agree on the algorithms to use or send an SSH_MSG_DISCONNECT message and terminate the connection.

Figure 7.28. Algorithm Negotiation and Key Exchange

Currently, only two key-exchange methods are defined: Diffie-Hellman group 1 SHA-1 and Diffie-Hellman group exchange SHA-1 (DHGEX). The Diffie-Hellman group 1 SHA-1 protocol uses a fixed group with which to make its calculations, whereas the Diffie-Hellman group exchange SHA-1 protocol negotiates the group to use, based on the desired size of the prime modulus (see Chapter 3).

In Figure 7.28, the peers have agreed to use the Diffie-Hellman group exchange SHA-1 protocol. They begin by deciding on the group to use and then perform the Diffie-Hellman exchange. We will study these messages in detail shortly.

Finally, the client sends an SSH_MSG_NEWKEYS message to the server. This message signals that the peers should begin using the previously agreed on encryption, integrity, and compression algorithms. As we'll discuss later, either peer may initiate a new key exchange at any time. After the negotiation, one peer will send the SSH_MSG_NEWKEYS message to start the use of the new keys. The format of the SSH_MSG_KEXINIT message is shown in Figure 7.29.

Figure 7.29. The SSH_MSG_KEXINIT Message

[View full size image]

The type field contains the message number: SSH_MSG_KEXINIT, in this case. The cookie field is not really a cookie, in the sense that the receiver will return it to the sender, but is simply a sequence of 16 random bytes. Because this field will be used in the key-generation process and because each side sends an independent value for this field, the cookie serves to ensure that neither side can completely determine the keys that the connection will use.

The next eight fields are lists of comma-separated algorithms that the sender supports. The lists are sorted in order of preference. We will see an example of these lists shortly. Most of these fields are self-explanatory. The host key algorithm field lists the types of host keys used for server authentication that the sender supports. Recall that in SSHv1, this was always an RSA key. SSHv2 supports additional methods.

The next two fields are lists of comma-separated language tags. The use of these tags is explained in RFC 3066 [Alvestrand 2001]. These lists are empty unless they are known to be needed by the sending party.

The kex field is a Boolean field that indicates whether a guessed key-exchange packet follows. The SSHv2 transport protocol allows each peer to guess what key-exchange protocol its peer will request and to send the initial key-exchange message immediately. If a guessed initial key-exchange packet follows, this field will be TRUE.

This capability adds complexity for little apparent benefitnever a good tradeoff in security software. OpenSSH always sets the kex field to FALSE but does, of course, honor its use by a peer.

Because no encryption is used until after the first SSH_MSG_NEWKEYS message, we can capture the entire algorithm and key-exchange protocol exchange of Figure 7.28. Here is a capture of an SSH_MSG_KEXINIT message:

1    15:12:17.920079 localhost.32775 > localhost.ssh: P 23:567(544)
     ack 24 win 32767 <nop,nop,timestamp 2036746 2036746> (DF)
1.1     4500 0254 001b 4000 4006 3a87 7f00 0001     E..T..@.@.:.....
1.2     7f00 0001 8007 0016 fded 9b30 fdd3 3e71     ...........0..>q
1.3     8018 7fff 2456 0000 0101 080a 001f 140a     ....$V..........
1.4     001f 140a 0000 021c 0914 752b cb0f 1554     ..........u+...T
1.5     933c a4d0 c8d9 f222 cbbb 0000 003d 6469     .<.....".....=di
1.6     6666 6965 2d68 656c 6c6d 616e 2d67 726f     ffie-hellman-gro
1.7     7570 2d65 7863 6861 6e67 652d 7368 6131     up-exchange-sha1
1.8     2c64 6966 6669 652d 6865 6c6c 6d61 6e2d     ,diffie-hellman-
1.9     6772 6f75 7031 2d73 6861 3100 0000 0f73     group1-sha1....s
1.10    7368 2d72 7361 2c73 7368 2d64 7373 0000     sh-rsa,ssh-dss..
1.11    0066 6165 7331 3238 2d63 6263 2c33 6465     .faes128-cbc,3de
1.12    732d 6362 632c 626c 6f77 6669 7368 2d63     s-cbc,blowfish-c
1.13    6263 2c63 6173 7431 3238 2d63 6263 2c61     bc,cast128-cbc,a
1.14    7263 666f 7572 2c61 6573 3139 322d 6362     rcfour,aes192-cb
1.15    632c 6165 7332 3536 2d63 6263 2c72 696a     c,aes256-cbc,rij
1.16    6e64 6165 6c2d 6362 6340 6c79 7361 746f     ndael-cbc@lysato
1.17    722e 6c69 752e 7365 0000 0066 6165 7331     r.liu.se...faes1
1.18    3238 2d63 6263 2c33 6465 732d 6362 632c     28-cbc,3des-cbc,
1.19    626c 6f77 6669 7368 2d63 6263 2c63 6173     blowfish-cbc,cas
1.20    7431 3238 2d63 6263 2c61 7263 666f 7572     t128-cbc,arcfour
1.21    2c61 6573 3139 322d 6362 632c 6165 7332     ,aes192-cbc,aes2
1.22    3536 2d63 6263 2c72 696a 6e64 6165 6c2d     56-cbc,rijndael-
1.23    6362 6340 6c79 7361 746f 722e 6c69 752e     cbc@lysator.liu.
1.24    7365 0000 0055 686d 6163 2d6d 6435 2c68     se...Uhmac-md5,h
1.25    6d61 632d 7368 6131 2c68 6d61 632d 7269     mac-sha1,hmac-ri
1.26    7065 6d64 3136 302c 686d 6163 2d72 6970     pemd160,hmac-rip
1.27    656d 6431 3630 406f 7065 6e73 7368 2e63     emd160@openssh.c
1.28    6f6d 2c68 6d61 632d 7368 6131 2d39 362c     om,hmac-sha1-96,
1.29    686d 6163 2d6d 6435 2d39 3600 0000 5568     hmac-md5-96...Uh
1.30    6d61 632d 6d64 352c 686d 6163 2d73 6861     mac-md5,hmac-sha
1.31    312c 686d 6163 2d72 6970 656d 6431 3630     1,hmac-ripemd160
1.32    2c68 6d61 632d 7269 7065 6d64 3136 3040     ,hmac-ripemd160@
1.33    6f70 656e 7373 682e 636f 6d2c 686d 6163     openssh.com,hmac
1.34    2d73 6861 312d 3936 2c68 6d61 632d 6d64     -sha1-96,hmac-md
1.35    352d 3936 0000 0009 6e6f 6e65 2c7a 6c69     5-96....none,zli
1.36    6200 0000 096e 6f6e 652c 7a6c 6962 0000     b....none,zlib..
1.37    0000 0000 0000 0000 0000 0000 0000 0000     ................
1.38    0000 0000                                   ....

On line 1.4 the length, pad len, and type fields are set in boldface. The length field is 540 (0x21c) bytes, which agrees with the total TCP segment length of 544 on line 1. Next is the pad len field, set to 9. The padding is the last 9 bytes of zeros in the packet; there is no MAC field yetthat field will be present after the SSH_MSG_NEWKEYS message. Finally, the message type is 20 (0x14), as expected.

The 16 bytes following the message type are the cookie. The lists of algorithms follow the cookie. For example, the list of key-exchange algorithms is on lines 1.51.9. We see that OpenSSH supports the diffie-hellman-group-exchange-sha1 and diffie-hellmangroup1-sha1 methods, as we discussed previously.

On lines 1.26 and 1.27 is an example of a "private algorithm." The MAC method hmac-ripemd160@openssh.com is defined by the OpenSSH organization. The @openssh.com identifies the method name space as belonging to the openssh.com domain. Other examples of private algorithms are found in the lists of encryption algorithmssee lines 1.151.17, for instance. Peers that don't know about these private methods will, of course, ignore them in the method-selection process. Methods assigned by IETF do not have the @ and domain name appended.

SSHv2 Diffie-Hellman Key Exchange Protocol

Returning to Figure 7.28, we see that the peers have agreed to use the Diffie-Hellman group exchange protocol for key exchange. The process begins with the client sending the server an SSH_MSG_KEXDH_GEX_REQUEST message, which specifies the maximum, minimum, and preferred prime size for the Diffie-Hellman group. The format of this message is shown in Figure 7.30. The type field is set to 34, indicating an SSH_MSG_KEXDH_REQUEST message. The min, preferred, and max fields are 32-bit unsigned integers specifying the minimum, preferred, and maximum size in bits of the prime for the group.

Figure 7.30. The SSH_MSG_KEXDH_REQUEST Message

The server selects a group of the appropriate size and informs the client of its choice with an SSH_MSG_KEXDH_GEX_GROUP message. This message (type 31) contains two multiprecision integers containing the chosen prime, p, and the corresponding generator g. After the client receives this message, both peers know the Diffie-Hellman group to use.

The next two messages complete the Diffie-Hellman key exchange. The client chooses a random number rC such that 1 < rC < (p - 1)/2, calculates e = grC mod p, and sends it to the server as a multiprecision integer in an SSH_MSG_KEXDH_GEX_INIT (type 32) message.

On receipt of the SSH_MSG_KEXDH_GEX_INIT message, the server chooses its own random number rS, calculates f = grS mod p, and sends this value along with its server key and the signature of the exchange hash, H, to the client in an SSH_MSG_KEXDH_GEX_REPLY message (Figure 7.31). We discuss the exchange hash shortly.

Figure 7.31. The SSH_MSG_KEXDH_GEX_REPLY Message

[View full size image]

The SSH_MSG_KEXDH_GEX_REPLY message serves two purposes. First, it provides the client with its part of the Diffie-Hellman calculation that both peers will use to derive a shared secret. This is the value f . As we saw in Chapter 3, the client calculates K = frC, and the server calculates the same value independently as K = erS.

Second, the message provides server authentication. By including the host key, the message allows the client to identify the server from its database of server keys. Thesignature of the exchange hash, H, allows the client to verify that the server possesses the private key corresponding to the public key in the message.

The Exchange Hash

We've already seen that the exchange hash plays a role in server authentication. The exchange hash also plays an important role in key generation and the prevention of replay attacks. Finally, the initial exchange hashthe one from the first key exchangeserves as the session ID.

Recall that the key-exchange algorithms include a hash method. In both of the currently defined key-exchange methods, this is the SHA-1 hash. In what follows, we'll call this hash function h(m).

The exchange hash is calculated as

H = h(S)

where S is the concatenation of the quantities shown in Figure 7.32.

Figure 7.32. Quantities in the Exchange Hash

Type

Value

Explanation

DHGEX Only

string

VC

client's version string (CR and NL excluded)

string

VS

server's version string (CR and NL excluded)

string

IC

payload of client's SSH_MSG_KEXINIT message

string

IS

payload of server's SSH_MSG_KEXINIT message

string

KS

host key

integer

min

minimum group size

•

integer

n

preferred group size

•

integer

max

maximum group size

•

multiprec. int.

p

prime

•

multiprec. int.

e

client's Diffie-Hellman calculation

multiprec. int.

f

server's Diffie-Hellman calculation

multiprec. int.

K

shared secret

Note that the quantities that make up the exchange hash are available to both the client and server. This fact allows the client to verify the server's signature of the exchange hash and both sides to independently generate the session keys.

Before leaving our discussion of key exchange, let's turn to the other method: Diffie-Hellman group 1 with SHA-1. The method is similar to Diffie-Hellman group exchange but uses a fixed group, so there is no group-size negotiation.

Using a single fixed group, as this method does, leaves the Diffie-Hellman exchange open to a precomputation attack. Most of the work involved in solving the discrete logarithm problem involves precomputation on the group and its generator defined by the values of g and p [Herzog 1999]. Using a fixed group makes it possible to perform these computations once offline and then use them repeatedly in different attacks.

It uses just two messages: the SSH_MSG_KEXDH_INIT (type 30) message, which is identical to the SSH_MSG_KEXDH_GEX_INIT message from the group exchange method, and the SSH_MSG_KEXDH_REPLY (type 31) message, which is identical to the SSH_MSG_KEXDH_GEX_REPLY message.

The group exchange method reuses message numbers from the group 1 method. Although this seems unnecessarily confusing, it allows new methods to be added without having to reserve message number ranges in advance. The first message in the exchange identifies the method, and the subsequent messages in the method can use any number in the range reserved for key exchange. We will see this reuse again in the authentication protocol.

Key Generation

The types of session keys and their calculation are shown in Figure 7.33. The peers will generate whichever keys are required for the chosen session algorithms. For example, the initial IVs are not required if the peers are using a stream cipher, such as RC4.

Figure 7.33. Session Key Generation

Key

Calculation

client to server initial IV

h(K || H || "A" | | SID)

server to client initial IV

h(K || H || "B" | | SID)

client to server encryption

h(K || H || "C" | | SID)

server to client encryption

h(K || H || "D" | | SID)

client to server integrity

h(K || H || "E" | | SID)

server to client integrity

h(K || H || "F" | | SID)

K = shared secret

H = exchange hash

SID = session ID

With the SHA-1 hash, each of the calculations shown in Figure 7.33 will generate 160 bits of key material. If additional bits are required, they are generated by hashing the concatenation of K, H, and the key so far. This process is continued until a sufficient number of bits are generated. For example, to extend the bits for the client to server encryption key, we would calculate

key1 = h(K || H || "C"| |SID)

key2 = h(K || H || key1)

key3 = h(K || H || key1 || key2)

. . .

key = key1 || key2 || key3 || . . .

Either peer can initiate a rekeying by sending an SSH_MSG_KEXINIT message. This process is the same as the initial algorithm negotiation and key generation, so the peers can even renegotiate the algorithms they will use, if desired. Because the peers will use new cookies for the SSH_MSG_KEXINIT messages and will calculate a new shared secret, the newly generated keys will be distinct from the old keys.

Rekeying after transmitting a certain amount of data is always a good idea because it makes it more difficult for an attacker to gather enough ciphertext for an effective cryptanalysis. With SSHv2, there is a more immediate reason for rekeying. Recall that each packet's MAC contains an implicit sequence number that is based on a 32-bit counter. If this counter is allowed to wrap while using the same keys, the session becomes subject to replay, information leakage, and out-of-order delivery attacks [Bellare, Kohno, and Namprempre 2002]. The draft SSHv2 transport protocol specification recommends that a session be rekeyed after each gigabyte of data or after an hour of connection time without rekeying.

During the rekeying operation, the peers use the old keys and algorithms. When the rekeying operation is complete, an SSH_MSG_NEWKEYS message signals the peers to begin using the new keying material and algorithms. The SSH specification is unclear on how rekeying should take place, and many implementations don't support it [Gutmann 2005].

Service Requests

After the key exchange, the transport protocol has established its secure data stream and is now ready to start carrying data for the authorization and connection protocols. To request one of these protocols, the client sends the server an SSH_MSG_SERVICE_REQUEST message containing the service name as a string. Currently, the specification defines the two services ssh-userauth and ssh-connection.

If the server supports the service request and is willing to let the client invoke it, the server will send the client an SSH_MSG_SERVICE_ACCEPT message, which echos the service name as a string. If the server does not support the service or is unwilling to let the client invoke it, it will send the client an SSH_MSG_DISCONNECT message.

The SSHv2 Authentication Protocol

When the authentication protocol begins running, the transport protocol has already authenticated the server to the client. The authentication protocol's purpose is to authenticate the userand sometimes the client hostto the server.

Four user authentication methods are defined: public key, password, keyboard interactive, and host based. The host-based method is similar to the rhosts/RSA method from SSHv1 and is inappropriate in most situations requiring serious security. We will not discuss this method further.

The public key and password methods are functionally similar to their counterparts in SSHv1, although the protocols implementing them are different. Keyboard interactive is a general method that encompasses any authentication algorithm that can be implemented on the client side by user keyboard interaction. The advantage of this method is that new algorithms can be implemented on the server side without requiring changes to the clients. This method can be used to implement challenge/response and one-time-password schemes in SSHv2 but finds its main use in the pluggable authentication modules (PAM) framework.

The general authentication message types are shown in Figure 7.34. We'll discuss other, method-specific messages, when we cover the method in question.

Figure 7.34. General Authentication Messages

No.

Message Name

Message

50

SSH_MSG_USERAUTH_REQUEST

authorization initiation

51

SSH_MSG_USERAUTH_FAILURE

server rejects authentication attempt

52

SSH_MSG_USERAUTH_SUCCESS

server accepts authentication

53

SSH_MSG_USERAUTH_BANNER

login banner from the server

All authentication methods are initiated by the client sending the server an SSH_MSG_USERAUTH_REQUEST message. The general format of this message is shown in Figure 7.35. The method-specific data varies with the particular authentication method.

Figure 7.35. General Format of the User Authentication Request

The type field is set to SSH_MSG_USERAUTH_REQUEST. The particular type of request is given as an ASCII string in the method name field.

The user name field contains the user's name encoded as a UTF-8 string. The service name contains the name of the service for which the user is asking to be authenticated. This field is encoded as an ASCII string.

The SSH_MSG_USERAUTH_FAILURE message, shown in Figure 7.36, is sent by the server to indicate partial success or complete failure of the authentication.

Figure 7.36. The SSH_MSG_USERAUTH_FAILURE Message

The authentications list field is a list of authentication methods that the client can try instead of the failed method. The flag field provides additional message-specific semantics.

When the client successfully completes authentication to the server's satisfaction, the server responds with an SSH_MSG_USERAUTH_SUCCESS message, which ends the authentication protocol successfully. This message contains no arguments.

The final general authentication message is the SSH_MSG_USERAUTH_BANNER message. The server sends this message to request that the client display a login banner to the user. The client may decide whether to display the message. The SSH_MSG_USERAUTH_BANNER contains two strings: a UTF-8 encode string with the message itself and an RFC 3066 language tag.

The "none" Authentication Method

In the SSHv1 protocol, the server sends the client a list of supported authentication methods in the SSH_SMSG_PUBLIC_KEY message at the beginning of the protocol exchange. In SSHv2, the client requests a list of supported authentication methods by sending an SSH_MSG_USERAUTH_REQUEST message specifying the "none" authentication message. If the server does not require authentication, it can reply with an SSH_MSG_USERAUTH_SUCCESS message, but the normal procedure is to return an SSH_MSG_USERAUTH_FAILURE message with a list of supported authentication methods in the authentications list field. There is no message-specific data in the SSH_MSG_USERAUTH_REQUEST message when the method name is set to none.

The Public Key Authentication Method

The public key authentication method is similar to the RSA method from SSHv1 but is generalized to support any signature method. As we see from the tcpdump of the SSH_MSG_KEXINIT, OpenSSH supports RSA and DSS signatures.

The client requests a public key authentication by sending an SSH_MSG_USERAUTH_REQUEST message with the method name set to "publickey." The method-specific data, shown in Figure 7.37, includes three strings containing the name of the signature algorithm, the public key, and the signature itself. The flag field is set to TRUE.

Figure 7.37. Method-Specific Data for the Public Key Method

The signature is taken over the data shown in Figure 7.38. Note that the public key authentication method is different from the challenge/response protocol used in SSHv1's RSA authentication. By sending the signature along with the request, the protocol saves two packet exchanges.

Figure 7.38. Data for the Public Key Signature

Type

Data

string

session ID

byte

SSH_MSG_USERAUTH_REQUEST

string

user name

string

service

string

"publickey"

Boolean

TRUE

string

algorithm name

string

public key

If the public key is not valid for this user or if the signature does not validate, the server will respond with an SSH_MSG_USERAUTH_FAILURE message. If both tests succeed and no further authentication is required, the server will respond with an SSH_MSG_USERAUTH_SUCCESS message, and the authentication will be complete.

Computing the signature is computationally expensive and may require user interaction if the private key is protected with a password. The protocol allows the client to verify that the public key and algorithm are acceptable to the server before asking the user for the password or calculating the signature. To do this, the client sends an SSH_MSG_USERAUTH_REQUEST message with the method-specific data, as shown in Figure 7.39. The flag field is set to FALSE to distinguish this message from an actual public key authentication request. The public key blob field contains the public key and, optionally, certificates or other information.

Figure 7.39. Message-Specific Data for the Public Key Test Message

The Password Authentication Method

From the user's perspective, the SSHv2 password authentication is identical to the SSHv1 version, except that the client or server may request the user to enter a new password. This last facility is usually used by the server when a user's password has expired. The client requests a password authentication by sending the server an SSH_MSG_USERAUTH_REQUEST message with the method name set to "password." The message-specific data consists of a flag set to FALSE and a string containing the password encoded in UTF-8.

Normally, the server will respond with an SSH_MSG_USERAUTH_SUCCESS or SSH_MSG_USERAUTH_FAILURE message but can also request a new password by sending an SSH_MSG_USERAUTH_PASSWD_CHANGEREQ message (Figure 7.40). The type field is set to SSH_MSG_USERAUTH_PASSWD_CHANGEREQ (60). The prompt field contains the user prompt in the language defined by the language tag field.

Figure 7.40. The Change Password Request Message

At this point, the client can either try another authentication message or retry the password authentication, using the message-specific data shown in Figure 7.41. In this case, the flag field is set to TRUE.

Figure 7.41. Method-Specific Data for the Change Password Message

The server responds to the client's change password message with one of the following: SSH_MSG_USERAUTH_SUCCESS, indicating that the password was changed and that the authentication was successful; SSH_MSG_USERAUTH_FAILURE, indicating that the password was changed but that more authentication is needed (partial success TRUE) or that the password was not changed (partial success FALSE), due to a bad old password or password changing not being supported; or SSH_MSG_USERAUTH_CHANGEREQ, indicating that the new password was not acceptable.

The Keyboard Interactive Authentication Method

The final authentication method that we look at is the keyboard interactive method, a generalized method that can support any authentication scheme that requires only user keyboard input. One could, in principle, use this method to do ordinary password authentication, but its main use is in challenge/response and one-time-password schemes.

The client requests keyboard interactive authentication by sending the server an SSH_MSG_USERAUTH_REQUEST message with the method type set to "keyboard-interactive," and the message-specific data shown in Figure 7.42. The language tag field, if not empty, indicates the language encoding that the user prompts should be in. The submethods field is a list of authentication methods that the client would like to try. The server treats this field as a hint and is free to try whatever method it chooses.

Figure 7.42. Message-Specific Data for the Keyboard Interactive Message

The server may respond with an SSH_MSG_USERAUTH_FAILURE message if it does not support keyboard interactive authentication or an SSH_MSG_USERAUTH_SUCCESS message if no further authentication is required. Normally, however, the server will respond with the SSH_MSG_USERAUTH_INFO_REQUEST (60) message shown in Figure 7.43.

Figure 7.43. The SSH_MSG_USERAUTH_INFO_REQUEST Message

[View full size image]

The name and instruction fields are displayed to the user. Either or both fields may be empty. The language tag field is intended to indicate to the client which language encoding should be used for the messages it displays to the users. The draft specification recommends that this field be empty and that the peers use the encodings negotiated during key exchange.

The number of prompts field tells the client how many prompt/echo pairs follow. These are labeled prompt1 . . . promptn and echo1 . . . echon in Figure 7.43. Each prompti field contains a prompt for the user ("Password:", for example), and the corresponding echoi flag tells the client whether to echo the response to the user's terminal.

On receipt of the SSH_MSG_USERAUTH_INFO_REQUEST message, the client displays the name and instruction fields on the user's display and then prompts the user with each of the included prompts, either echoing the response or not, as indicated by the corresponding echo flag. The server can send additional SSH_MSG_USERAUTH_INFO_REQUEST messages but only after the client responds to the current one.

After prompting the user and gathering the replies, the client will respond with an SSH_MSG_USERAUTH_INFO_RESPONSE message (Figure 7.44). The number of responses field must contain the same number as the server's number of prompts field. The responsei fields carry the user's response to the server's prompts.

Figure 7.44. The SSH_MSG_USERAUTH_INFO_RESPONSE Message

[View full size image]

The Connection Protocol

After authentication, SSH starts the ssh-connection service, which handles remote shells, remote execution of commands, X11 forwarding, and TCP/IP port forwarding. With the exception of file transfer utilities, such as scp, these services are implemented similarly to the way they were in SSHv1.

As in SSHv1, multiple channels can be multiplexed onto the secure data stream provided by the transport protocol. As a result, there are two classes of messages in the connection protocol: channel messages, which apply to a particular channel, and global messages, which are not associated with a channel. The message types and numbers are given in Figure 7.45.

Figure 7.45. SSHv2 Channel Messages

No.

MessageName

Message

80

SSH_MSG_GLOBAL_REQUEST

global message

81

SSH_MSG_REQUEST_SUCCESS

global message succeeded

82

SSH_MSG_REQUEST_FAILURE

global message failed

90

SSH_MSG_CHANNEL_OPEN

channel open request

91

SSH_MSG_CHANNEL_OPEN_CONFIRMATION

channel open request succeeded

92

SSH_MSG_CHANNEL_OPEN_FAILURE

channel open failed

93

SSH_MSG_CHANNEL_WINDOW_ADJUST

open flow control window

94

SSH_MSG_CHANNEL_DATA

data-bearing message for a channel

95

SSH_MSG_CHANNEL_EXTENDED_DATA

extended channel data (STDERR, e.g.)

96

SSH_MSG_CHANNEL_EOF

end of file for channel data

97

SSH_MSG_CHANNEL_CLOSE

channel close request

98

SSH_MSG_CHANNEL_REQUEST

channel-specific request

99

SSH_MSG_CHANNEL_SUCCESS

channel request succeeded

100

SSH_MSG_CHANNEL_FAILURE

channel request failed

The global request message has the general form shown in Figure 7.46. The type field is set to SSH_MSG_GLOBAL_REQUEST, and the specific request is carried as an ASCII string in the request name field. The want reply field is a Boolean that's set to TRUE if the sender wants a reply to the request and FALSE otherwise. When the want-reply flag is TRUE, the peer will respond with either an SSH_MSG_REQUEST_SUCCESS or an SSH_MSG_REQUEST_FAILURE message. Both of these messages normally have only a type field, but the SSH_MSG_REQUEST_SUCCESS message may include data specific to the request that it is acknowledging.

Figure 7.46. General Form of the SSH_MSG_GLOBAL_REQUEST Message

The SSH_MSG_CHANNEL_OPEN, SSH_MSG_CHANNEL_OPEN_CONFIRMATION, and SSH_MSG_CHANNEL_OPEN_FAILURE messages have similar general forms. The SSH_MSG_CHANNEL_OPEN message, shown in Figure 7.47, requests that the peer allocate a new data channel. As we've seen before, each peer will have its own channel number. The sender channel field is the number that the message sender has assigned to the channel. The channel type field is the type of channel that the sender is requesting. This field is encoded in ASCII.

Figure 7.47. General Form of the SSH_MSG_CHANNEL_OPEN Message

[View full size image]

The initial window size field is used for flow control. The maximum packet size field indicates the largest packet that the sender is willing to receive from its peer.

If the peer agrees to open the channel, it will respond with an SSH_MSG_CHANNEL_OPEN_CONFIRMATION message (Figure 7.48). The recipient channel is the channel number that the original sender assigned in the SSH_MSG_CHANNEL_OPEN message. The sender channel is the channel number that this sender is assigning. The other fields are identical to those in the SSH_MSG_CHANNEL_OPEN message.

Figure 7.48. General Form of the SSH_MSG_CHANNEL_OPEN_CONFIRMATION Message

If the peer cannot or is unwilling to open the channel, it will reply with the SSH_MSG_CHANNEL_OPEN_FAILURE message, shown in Figure 7.49. The reason code field is a numeric value giving the reason for the failure. Currently defined values are given in Figure 7.50. The textual information field gives further information about the failure. It is intended for human consumption. The language tag field indicates the language for the textual information field.

Figure 7.49. The SSH_MSG_CHANNEL_OPEN_FAILURE Message

[View full size image]

Figure 7.50. Channel Open Failure Reason Codes

Code

Value

SSH_OPEN_ADMINISTRATIVELY_PROHIBITED

1

SSH_OPEN_CONNECT_FAILED

2

SSH_OPEN_UNKNOWN_CHANNEL_TYPE

3

SSH_OPEN_RESOURCE_SHORTAGE

4

Data Transfer

Data transfer in SSHv2 is flow controlled in a manner vaguely reminiscent of TCP's flow control. Each side maintains a "window" that its peer can send data into. When the window is filled up, the peer must stop sending data. As buffer space becomes available, the receiving side informs its peer by sending a SSH_MSG_CHANNEL_WINDOW_ADJUSTMENT message that indicates how many more bytes the peer can send. This message contains two unsigned integers: the recipient channel number and a bytes to add field that indicates how much to expand the window.

Data is carried in SSH_MSG_CHANNEL_DATA messages. These messages have two fields: the usual recipient channel number and the data itself, carried as a string.

Because a channel can carry more than one type of data, an SSH_MSG_CHANNEL_EXTENDED_DATA message (Figure 7.51) carries the other data types. Currently, this message is used only to carry STDERR data in interactive sessions. The data type field indicates the type of extended data the message is carrying. The only defined type at this writing is SSH_EXTENDED_DATA_STDERR (1).

Figure 7.51. The SSH_MSG_CHANNEL_EXTENDED_DATA Message

[View full size image]

When finished sending data on a channel, a peer can send an SSH_MSG_CHANNEL_EOF message. This message contains a single unsigned integer carrying the recipient's channel number. The message does not close the channel, and the other side may continue to send datain this respect, it is like the TCP EOF that merely indicates that one side has finished sending data.

Either peer can close the channel by sending an SSH_MSG_CHANNEL_CLOSE message, which again contains only the recipient's channel number. The peer receiving this message must respond with its own SSH_MSG_CHANNEL_CLOSE message, after which no further data can be sent by either side.

Shell and Remote Command Sessions

To start a shell session or execute a remote command, the client opens a session channel by sending the server an SSH_MSG_CHANNEL_OPEN message with the channel type set to "session." If needed, the client can request a pseudo-tty terminal by sending an SSH_MSG_CHANNEL_REQUEST message. The general form of this message is shown in Figure 7.52.

Figure 7.52. The SSH_MSG_CHANNEL_REQUEST Message

To request a pseudo-tty, the request type field is set to "pty-req." The additional information shown in Figure 7.53 is also included. This message is almost identical to the SSHv1 SSH_CMSG_REQUEST_PTY message.

Figure 7.53. Message-Specific Data for a Pseudo-TTY Request

If the want reply flag is TRUE, the server will reply with either an SSH_MSG_CHANNEL_SUCCESS or an SSH_MSG_CHANNEL_FAILURE message. Both of these messages have a single argument carrying the recipient channel number.

Once the channel is established and a pseudo-tty is started, if needed, the client can request the server to either start a shell or execute a command by sending another SSH_MSG_CHANNEL_REQUEST message. These commands have the request type field set to either "shell" or "exec." When the request type is "exec," an additional string parameter carries the name of the command to execute. Before starting the shell or command, the client can set environment variables for them by sending an SSH_MSG_CHANNEL_REQUEST message with the request type field set to "env." Two strings in the request-specific data contain the variable name and its value.

When it terminates, the command or shell can return an exit status to the client by sending an SSH_MSG_CHANNEL_REQUEST with the request type field set to "exit-status," and an additional unsigned integer containing the exit status. The want reply flag must be set to FALSE for this message.

If the shell or command terminates prematurely with a signal, the server sends an SSH_MSG_CHANNEL_REQUEST message with the request type field set to "exit-signal." Additional data about the signal is included in the message-specific data, as shown in Figure 7.54. As with the "exit-status" message, the want reply field is set to FALSE. The core dumped flag is set to TRUE if a core dump resulted and to FALSE otherwise.

Figure 7.54. Request-Specific Data for the Exited with Signal Message

[View full size image]

The client can send a signal to the command or shell executing on the server by sending the server an SSH_MSG_CHANNEL_REQUEST message with the request type field set to "signal." The message-specific data is a string containing the name of the signal, without the "SIG." As with the exit messages, the want reply flag is set to FALSE. Not all servers implement signals, of course, so the server will ignore this message if it does not support signals or does not recognize the signal type.

Two other channel messages are associated with interactive sessions. The first is the "window-change" request, which informs the server of a change in the client's terminal window dimensions. The message-specific data comprises four unsigned integers that contain the window's new width and height, first in columns and rows and then in pixels. The want reply flag is FALSE.

The other message type associated with interactive sessions is the "xon-xoff" message, which allows the client to do manual (^S/^Q) flow control. The server sends this message to the client to tell it whether the client can do manual flow control. The message-specific data is a single Boolean flag, can do, which is TRUE if the client is allowed to perform manual flow control and FALSE otherwise. The want reply flag is FALSE for this message.

X11 Forwarding

X11 forwarding under SSHv2 works pretty much the way it does under SSHv1. The client requests forwarding by sending the server an SSH_MSG_CHANNEL_REQUEST message with the request type set to "x11-req." The request-specific information is shown in Figure 7.55. The single connection field is a Boolean that indicates whether the server should accept multiple X11 connections. The other fields serve the same purposes they did in SSHv1 X11 forwarding.

Figure 7.55. Request-Specific Data for the X11 Forwarding Request Message

[View full size image]

When an X11-client connects to the proxy server, the SSH server opens a channel to the client by sending an SSH_MSG_CHANNEL_OPEN message, with the channel type set to "x11." The request-specific data comprises a string containing the originator's address and an unsigned integer containing the originator's source port. As usual, the client is expected to reply with either an SSH_MSG_CHANNEL_OPEN_CONFIRMATION or an SSH_MSG_CHANNEL_OPEN_FAILURE message.

Port Forwarding

As with X11 forwarding, SSHv2 port forwarding is similar to its SSHv1 counterpart. The client may forward a local port to the server at any time by sending the server an SSH_MSG_CHANNEL_OPEN message with the channel type field set to "direct-tcpip." The request-specific data, shown in Figure 7.56, indicates the host and port to connect to and the host and port of the connection's originator.

Figure 7.56. Request-Specific Data for a Local Port Forwarding Message

[View full size image]

Remote port forwarding is handled just as it is in SSHv1. The client requests the server to forward a port to it by sending an SSH_MSG_GLOBAL_REQUEST message with the request type set to "tcpip-forward." The request-specific data comprises a string containing the address to bind and an unsigned integer containing the port to forward. If the client specifies 0 as the port to forward, the server will bind the next available port number. In this case, if the want reply flag is TRUE, the server's SSH_MSG_GLOBAL_REQUEST_SUCCESS message will include an integer indicating the port bound.

When it connects to the server, a remote host will send the client an SSH_MSG_CHANNEL_OPEN message with the channel type field set to "forwarded-tcpip." The request-specific data, shown in Figure 7.57, contains the address and port that was connected to and the originator's address or port.

Figure 7.57. Request-Specific Data for a Remote Port Forwarding Message

[View full size image]

The client can cancel a forwarding request by sending the server an SSH_MSG_GLOBAL_REQUEST message with a request type of "cancel-tcpip-forward," message-specific data comprising a string with the address that was bound, and an unsigned integer containing the port that was bound.

Subsystems

SSHv2 introduced a new abstraction layer called subsystems. A good way of understanding subsystems is to think of them as a sort of inetd for SSH. The idea is that the server's system administrator can give arbitrary names to commands that the client may request the server to run.

The most common example is sftp, an alternative interface to the scp functionality. Under SSHv2, sftp is defined as a subsystem. Thus, when the sftp client runs, it spawns ssh as a subprocess and asks it to run the sftp subsystem on the server. From a functional point of view, this is identical to what happens with SSHv1 except that the name of the process implementing the sftp server need not be "sftp" or even known by the client at all.

The server's system administrator configures the sftp subsystem by providing a mapping between the subsystem name and the name and path of the program implementing it. The system administrator can configure arbitrary subsystems by merely providing a mapping between the subsystem name and the command implementing it. For example, we could implement an rbiff subsystem by mapping the subsystem name "rbiff" to the command rbiffd. A more realistic example of SSH subsystems is at <http://www.columbia.edu/kermit/skermit.html>, which describes how to run kermit as an SSH subsystem.

Pushing our inetd analogy a little further, some systems could be implemented internally by sshd, much like the echo command is implemented internally by most implementations of inetd. Currently, no subsystems are implemented in this way, but the capability exists.

The client requests the server to invoke a subsystem by sending the server an SSH_MSG_GLOBAL_REQUEST message with the request type field set to "subsystem." The message carries the name of the system in the message-specific information as a string.

Security Issues with SSHv2

As we remarked earlier, SSHv2 was written to address certain security flaws in SSHv1. Although no defects as devastating as the CRC-32 MAC exploit have been discovered in SSHv2, some problems need to be addressed. A simple chosen plaintext attack, usually called Rogaway's attack, against block ciphers in CBC mode is described in [Dai 2002]. The attack requires knowing what the next IV for the block cipher will be, but in CBC mode, one need merely observe the previous cipher block, because it will be used as the next IV.

In Rogaway's attack, the attacker suspects that the value of plaintext block Pi is X and wants to verify that guess. The attacker observes that the last cipher block sent was Cj-1 and so chooses the plaintext block Pj = X [image] Ci-1 [image] Cj-1 to be encrypted. Now with CBC mode, we have

Cj = EK(Pj [image] Cj-1) = EK(X [image] Ci-1 [image] Cj-1 [image] Cj-1) = EK(X [image] Ci-1)

so if Cj = Ci, the attacker will have verified that X = Pi.

The attack is a little more difficult than indicated, because the first block of a packet starts with the two length fields (40 bits), over which the attacker does not have complete control. This implies that the attacker may have to wait several packets to launch the attack. See [Bellare, Kohno, and Namprempre 2002] for a complete analysis.

Dai recommended using RC4 to avoid this problem. The draft SSH architecture document from the IETF SECSH working group recommends the insertion of SSH_MSG_IGNORE messages to ensure that the attacker will not know the next IV.

Another attack on the SSHv2 transport protocol is described in [Bellare, Kohno, and Namprempre 2002]. The attack is a chosen ciphertext attack that also takes advantage of CBC mode. The idea is that the attacker knows one message Mi and suspects that another message, Mj, is identical or related to it. The attacker can verify this guess by sending the receiver specially crafted ciphertext. If the guess is correct, the receiver will accept the ciphertext as legitimate. If the guess is incorrect, the message will fail the authentication step, and the receiver will disconnect. The details of the attack are in [Bellare, Kohno, and Namprempre 2002].

We can make two observations about these attacks. First, neither approaches the seriousness of the attacks on SSHv1. The most the attacker can do is verify a previous guess as to the value of a block or that two blocks are the same or related. Second, both attacks depend on the underlying encryption using CBC mode.

The second observation suggests that we should consider using something other than a block cipher in CBC mode for encryption. As Dai suggests, RC4 is one possible alternative. [Bellare, Kohno, and Namprempre 2002] considers several other alternatives and concludes that using block encryption in CTR mode is the best solution. The authors have submitted a draft RFC to the SECSH working group, recommending that CTR mode be added to the list of supported block ciphers. The authors also provide tighter bounds on the amount of data that the SSHv2 transport layer can safely send before rekeying.

At the current time, SSHv2 appears to be reasonably secure. The known exploits are difficult to mount and yield relatively small results. These exploits depend on weaknesses in the CBC mode of block ciphers and can therefore be avoided by using RC4 or by using CTR mode instead of CBC mode with block ciphers. The modularity of the SSHv2 architecture and the ability to negotiate the security mechanisms for each session make it easy for SSHv2 to adapt to newly discovered exploits.

As always, we should keep in mind that a secure application can be attacked in many ways, some not directly aimed at the cryptographic mechanisms. For example, an interesting side-channel attack on SSH is described in [Song, Wagner, and Tian 2001]. In this attack, keystroke timings from an interactive SSH session are measured by observing the packet times. Statistical techniques are used to infer information about the text, including in some cases the text typed. One application of these techniques was able to reduce the work in an exhaustive search for passwords by a factor of 50. This attack depends on the fact that in interactive mode, SSH sends each character typed in a separate packet.


Section 7.4. Building VPNs with SSH

7.4. Building VPNs with SSH

We have already seen how SSH can provide a secure tunnel between applications, and in this sense, it might be said to function as a VPN as we've previously defined that term. In this section, we show how to use SSH to join two networksinstead of two applicationswith a secure tunnel.

Like its SSL counterpart, this VPN can suffer from performance problems due to the interactions between two instances of TCP. For this reason, the VPNs that we describe are probably not suitable for production environments, but they are easy to set up and so make excellent ad hoc solutions to small problems or as a way of temporarily linking two networks with a VPN.

In Chapter 6, we built our VPN by running PPP through an SSL connection. We could do that here as well in an essentially identical way.

An example of this using Linux is provided in [Kolesnikov and Hatch 2002].

Instead of using PPP, we illustrate another method by making use of a gtunnel-based application that we call sshvpn.

We set up our tunnel between bsd and laptop, using the architecture shown in Figure 7.58.

Figure 7.58. Architecture for the SSH VPN

[View full size image]

Notice that the figure is similar to Figure 7.22: sshvpn starts an SSH client, with which it communicates via pipes. The SSH client, in turn, connects to the SSH server on laptop, and the SSH server starts another instance of sshvpn, which it communicates with via pipes. As in Figure 7.22, we have shown the two spawned processes as dashed boxes. All communication between the two instances of sshvpn TRavels through the SSH tunnel and so is encrypted and authenticated.

The rest of Figure 7.58 shows that the two instances of sshvpn are connected to their hosts' TCP/IP stacks via the tun0 interface. Thus, data written into the tun0 interface on bsd will be read by the sshvpn on bsd, sent through the SSH tunnel to the sshvpn on laptop, and, finally, written into the tun0 interface on laptop by the sshvpn running there.

The figure is a little misleading because the traffic that flows through the SSH tunnel must first travel through the TCP/IP stack again. For clarity, we have omitted showing that path.

A convenient way of visualizing this process is to think of the sshvpn/ssh combination on bsd and the sshvpn/sshd combination on laptop as network interfaces that happen to communicate with each other using the SSH protocol. To the applications that use the VPN, the tun0 interface appears to be exactly this. On the one hand, it appears like any other network interfacean Ethernet interface, sayand on the other hand, it communicates with its peer interface over an SSH tunnel.

The sshvpn Application

As with our gtunnel-based IP-in-IP tunnel from Chapter 4, we need specify only startup, inbound, and outbound functions to add to our gtunnel skeleton. Let's begin with startup (Figure 7.59). This function behaves differently, depending on whether it is run on the local (SSH client) side or the remote (SSH server) side. On the local side, it must start ssh and establish the pipes between ssh and itself. On the remote side, sshvpn will be started by sshd, so startup need only map infd and outfd to STDIN and STDOUT. We signal which action startup should perform by calling sshvpn with a single parameter containing our peer's name or address when on the local side and with no parameters on the remote side.

Figure 7.59. The sshvpn startup Function

[View full size image]

startup

611

We first test whether the program was started on the local or the remote side. If called with no parameters, the program was spawned by sshd, so we need only map STDIN and STDOUT onto infd and outfd.

1213

If the program reaches this point, it is operating on the local side, so we must start ssh. We start by allocating two pipes, one each for input and output.

1416

The call to fork spawns a child process that is identical to its parent, so there are now two copies of sshvpn running. In the parent process, fork will return the process ID of the child. In the child process, fork will return 0. This return value is the only difference between the parent and child at this point.

1724

If this is the parent process, we close the write end of the input pipe and the read end of the output pipe, map the pipes onto the infd and outfd file descriptors, and return to the main function.

2531

In the child process, we map the pipes onto STDIN and STDOUT and close the read end of STDOUT and the write end of STDIN. Notice that the meanings of pipein and pipeout are reversed in the childthat is, the "in" and "out" are from the perspective of the parent process. Finally, we exec ssh. The execl call causes the ssh image to be read on top of the sshvpn process running in the child process. After this call, the child process is running ssh, not sshvpn. The execl call is the same as if we had invoked ssh on the command line as

ssh remote_host_name /home/jcs/bin/sshvpn

If the execl call is successful, it will not return (because ssh is running instead of sshvpn), so it's an error if it does return.

The outbound function is shown in Figure 7.60.

Figure 7.60. The sshvpn outbound Function

[View full size image]

outbound

3739 | The outbound function is very simple. It merely reads IP datagrams from the TCP/IP stack and
4042 | writes them into the pipe for delivery to SSH.

The inbound function, shown in Figure 7.61, is equally simple.

Figure 7.61. The sshvpn inbound Function

[View full size image]

inbound

4852 | The function reads an IP datagram from SSH. If it gets an EOF from its peer, it terminates sshvpn, thus tearing down the VPN.
53 | The IP datagram from our peer is sent up the TCP/IP stack by writing it to the tunnel device (tun0).

Running sshvpn

Running the sshvpn program is easy. After configuring the tun0 devices on bsd and laptop, we start sshvpn:

bsd# ./sshvpn laptop
Password:                                       enter laptop's root password
                                                VPN runs until we kill it
^CKilled by signal 2.                           VPN killed

The password prompt is from SSH, asking us to authenticate ourselves to the SSH server on laptop. After the authentication, sshd on laptop starts a local copy of sshvpn, and the VPN is up and ready to pass traffic. We can test this by pinging laptop from bsd:

$ ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=2.999 ms
64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=2.600 ms
64 bytes from 192.168.2.1: icmp_seq=2 ttl=64 time=1.791 ms
64 bytes from 192.168.2.1: icmp_seq=3 ttl=64 time=1.741 ms
^C
--- 192.168.2.1 ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 1.741/2.283/2.999/0.536 ms

As in the case of our SSL VPN from Chapter 6, it is instructive to consider what the packets traveling through the tunnel look like. In the case of our pings from the preceding example, we have Figure 7.62.

Figure 7.62. SSH VPN Datagram Format

[View full size image]

In this case, the ping packet is 84 bytes. The entire packet is 176 bytes, so there is a 92-byte overhead (55 percent). This overhead would be less dramatic if the payload packet were larger. For example, the overhead would be only 7 percent for a 1,300-byte payload.

As with all VPNs that use TCP as a transport medium, the more significant overhead is with round-trip time. The average ping response was 2.283 milliseconds, which is comparable to what we saw with the SSL VPN in Chapter 6. As before, the ping response times over the LAN, without the VPN, are about an order of magnitude less:

$ ping laptop
PING laptop.jcs.local (172.30.0.6): 56 data bytes
64 bytes from 172.30.0.6: icmp_seq=0 ttl=64 time=0.252 ms
64 bytes from 172.30.0.6: icmp_seq=1 ttl=64 time=0.258 ms
64 bytes from 172.30.0.6: icmp_seq=2 ttl=64 time=0.357 ms
64 bytes from 172.30.0.6: icmp_seq=3 ttl=64 time=0.262 ms
^C
--- laptop.jcs.local ping statistics ---
4 packets transmitted, 4 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.252/0.282/0.357/0.043 ms

As mentioned in Chapter 6, the ping test is optimal in the sense that the payload is not TCP, so there are not two instances of TCP with competing reliability mechanisms.

SSH VPNs are easy to set up and may make sense if performance is not an issue or if the majority of the traffic will be UDP datagrams. SSH VPNs are especially handy for temporary ad hoc VPNs.


Section 7.5. Summary

7.5. Summary

In this chapter, we studied the SSH protocol, a drop-in replacement for telnet, ftp, and the BSD r-commands. The protocol has two incompatible versions, but most implementations support them both.

SSHv1, the older protocol version, can provide a secure remote shell session, a secure channel between any two distributed applicationswhether or not they are SSH-awareX11 and port forwarding, and the secure file copy utility, scp. The server and user authentication mechanisms that SSHv1 uses ensure that the SSH client is talking to the correct server, and that the user is authorized to connect to the server.

Finally, SSHv1 has fundamental security problems. The chief problem is the use of a CRC as a MAC for authenticating messages. These problems led to the development of SSHv2.

SSHv2 is a completely different protocol. It replaces the monolithic architecture of SSHv1 with a layered architecture where an SSHv2 transport protocol provides a vehicle for the SSHv2 authentication and connection protocols. The server authentication mechanism is also different from that of SSHv1.

We concluded our examination of SSHv2 by looking at its security properties, and saw that the only attacks are not very serious and can, in any event, be avoided by not using CBC mode while encrypting. We concluded that SSHv2 provides good security and provides a flexible infrastructure that will allow it to adapt to changing conditions.

Finally, we used SSH and our gtunnel skeleton to build a VPN between two machines. As with our SSL VPN from Chapter 6, this VPN is not appropriate for high-volume production work but can be useful for ad hoc and temporary solutions to problems requiring a VPN.


Exercises

7.1 | In SSHv2 key generation, both the session ID and the exchange hash are included in the key calculation (Figure 7.33). Given that the session ID has the same value as the exchange hash, why are they both included?
7.2 | In the SSHv2 public key authentication method, the server does not send the client a challenge, as in the SSHv1 RSA method, but sends a signature over predetermined data (see Figure 7.38). Explain why the SSHv2 method is resistant to replay attacks.
7.3 | Show how to build an SSH VPN between two networks by using PPP instead of gtunnel.
7.4 | In principle, it would be possible to build a hardware implementation of our SSH VPN by embedding a TCP/IP stack and SSH protocol firmware into an Ethernet card. Is this a practical suggestion? Why or why not? Notice how Figure 7.22 becomes an exact depiction of the network architecture if we do this.


Chapter 8. Lightweight VPNs

    Section 8.1. Introduction

    Section 8.2. VTun

    Section 8.3. CIPE

    Section 8.4. Tinc

    Section 8.5. OpenVPN

    Section 8.6. Summary

    Exercises


Section 8.1. Introduction

8.1. Introduction

In this chapter, we discuss some lightweight VPNs, so called because they require fewer resources than do full-blown IPsec installations and are easier to install and maintain. As we shall see, this simplicity comes at the cost of decreased security.

We study four typical lightweight VPNs: VTun, CIPE, tinc, and OpenVPN. Three of these VPNs have the advantage that they are implemented in user space and are thus portable to several different platforms. It also means that installation and maintenance are easier because we don't have to deal with kernel updates or patches, and because problems with the VPN are much less likely to cause the operating system to crash.

As with all VPNs, these programs attempt to provide a secure tunnel between two networks or between a single computer and a network. The type of security offered for the tunnel varies among the four programs, and we shall pay special attention to that security as we study each type of VPN.


Section 8.2. VTun

8.2. VTun

VTun (Virtual Tunnel) is a simple VPN that uses the tun device (FreeBSD, OpenBSD, NetBSD) or the tun/tap device (Linux, Solaris) to copy packets between the TCP/IP stack and the vtund program running in user space. Architecturally, VTun is similar to the SSH VPN that we built in Chapter 7.

VTun supports four types of tunnels:

IP | IP datagrams, after encryption and optional compression, are carried as payload data in either TCP segments or UDP datagrams.
Serial | VTun provides a virtual PPP connection, similar to that in Figure 4.3, in which the PPP frames are encrypted, optionally compressed, and transported in either TCP segments or UDP datagrams
Ethernet | After encryption and optional compression, Ethernet frames are carried as payload data in either TCP segments or UDP datagrams. This type of tunnel is similar to the IP tunnel except that Ethernet frames instead of IP datagrams are tunneled. This means that any type of network-layer protocol, not just IP, can be carried in the tunnel as long as it can use Ethernet as the interface layer.
Pipe | This type of tunnel is similar to using SSH to tunnel a user command. The input and output of the tunnel are pipes, so the output from a local program can be fed directly to the tunnel, which pipes it to the input of another program on the remote host. This type of tunnel is a sort of superpipe that operates across a network while encrypting/compressing the data it carries.

All these tunnels are similar to ones that we saw in Chapter 4. The IP and Ethernet tunnels merely connect the user-space vtund application to the bottom of the TCP/IP stack through the tun or tun/tap device. This configuration is illustrated in Figure 8.1.

Figure 8.1. IP and Ethernet Tunnels with VTun

[View full size image]

As with Figure 7.58, this diagram is a little misleading because the traffic flowing through the tunnel must first travel through the TCP/IP stack again.

The configuration for the serial tunnels is similar to that shown in Figure 8.1, except that IP datagrams from the stack are first delivered to the PPP routines, where they are encapsulated into PPP frames. In the case of Linux and Solaris, the PPP routines are part of the kernel. In the case of FreeBSD, the PPP functionality is provided by another user-space application. In either case, the PPP frame is delivered to vtund, which sends it through the tunnel to the peer PPP routines in the remote host.

The configuration for the VTun pipe tunnels is shown in Figure 8.2.

Figure 8.2. The VTun Pipe Tunnel

[View full size image]

In this case, each user application talks directly to vtund through pipes rather than using the TCP/IP stack. With this type of tunnel, vtund is providing application-to-application connectivity rather than a network-to-network connectivity.

Data entering a VTun tunnel can be operated on by any combination of three modules. The first module compresses the data, using either ZLIB, when TCP carries the payload, or LZO, when UDP carries the payload. The second module encrypts the data, and the third module performs traffic shaping by limiting the amount of bandwidth that a particular tunnel can use. The modules to use are chosen by a configuration file, as are the other tunnel parameters.

The VTun Authentication Procedure

In a VTun VPN, one gateway plays the role of a server, and its peer gateway plays the role of a client. The vtund process can operate in either role. During tunnel establishment, the client authenticates itself to the server with the challenge/response protocol shown in Figure 8.3.

Figure 8.3. The VTun Authentication Protocol

When the client connects, the server informs the client of its version by sending a string of the form VTUN server ver 2.6 10/05/2004. The client responds with its host name by sending a string of the form HOST: linuxlt. When it receives the client's host name, the server generates a 16-byte random number and sends it to the client as a string of the form OK CHAL: <xxx>, where xxx is the challenge encoded as 32 characters from the set {a,. . . , p}, each character representing 4 bits of the challenge.

The client encrypts the challenge with a shared secret that it obtains from the configuration file and returns it to the server as a string of the form CHAL: <yyy>, where yyy is the encrypted challenge encoded as 32 characters from {a,. . . , p}, as before. If the decrypted challenge is correct, the server signals its acceptance of the client's authentication by returning the string OK FLAGS: <PtO>, where PtO is a set of character flags that describe the tunnel parameters. If the client fails the authentication, the server returns the string ERR.

The P flag indicates whether the payload should be carried in TCP (T) segments or UDP (U) datagrams. The t flag indicates the type of tunnel: u for IP, e for Ethernet, t for serial, or p for pipe.

There are five possible options, three of which take values. The options and values are shown in Figure 8.4.

Figure 8.4. VTun Tunnel Parameter Options

Option

Value

Meaning

S

bandwidth

limit amount of bandwidth for the tunnel

C

level

use ZLIB compression at the specified level

L

level

use LZO compression at the specified level

K

keep-alive flag

E

encrypt tunnel data

After authentication, traffic can begin flowing through the tunnel. As it enters the tunnel, traffic is first compressed, if desired, then encrypted. If traffic shaping was selected, it is applied to the data after encryption. Finally, the data is encapsulated in a TCP segment or a UDP datagram and sent to the peer gateway, where these steps are reversed.

A typical UDP encapsulation for an IP tunnel is shown in Figure 8.5.

Figure 8.5. VTun IP in UDP encapsulation

[View full size image]

Because the encrypted data is carried within a UDP datagram, VTun will not experience problems with NAT/PAT. PAT will use the port fields from the unencrypted UDP header (Figure 2.14) to map IP datagrams between the internal and external addresses. Similarly, when the tunnel uses TCP to carry the encrypted data, PAT can use the TCP port fields (Figure 2.16) for the mapping. Using UDP encapsulation has the advantage that the VPN will not suffer from the problems that we saw in Chapter 6 and Chapter 7 of having two reliability layers.

VTun Security

VTun uses the OpenSSL library (Chapter 6) to provide encryption services but does not make use of the SSL protocol itself. Rather, VTun uses SSL merely to provide the encryption algorithm it uses for authentication and encryption, the SSL MD5 implementation it uses to convert a shared secret to an encryption key, and the SSL random-number generator it uses to create the random challenge.

If the SSL library is not available, VTun will not encrypt the tunnel traffic but will still use the challenge/response protocol for authentication. Unfortunately, VTun generates the random challenge by using the standard C library function rand (seeded with the current time) and encrypts it by exclusive-ORing the shared secret into the challenge. As we saw in Chapter 3, these are fatal practices. In VTun's case, this is especially deadly because the challenge is available to an attacker as both plain- and ciphertext. This means that the attacker can trivially recover the shared secret (see Exercise 8.2).

As of this writing, the current stable version of VTun is version 2.6. This version supports only 128-bit Blowfish encryption, which it uses in ECB mode (Chapter 3) for both client authentication and encryption of the tunnel data.

Version 3 of VTun will support AES and Blowfish in several modes with key sizes of 128 or 256 bits.

As we saw in Chapter 3, ECB mode allows an attacker to identify identical blocks in the ciphertext, subjects the cipher stream to replay attacks, and makes insertion and cut-and-paste attacks particularly easy. For these reasons, the use of ECB mode in a VPN is a serious weakness.

This weakness is compounded by the fact that VTun does not use a MAC to authenticate each data block. As we've seen, this is another serious weakness that opens the cipher stream up to manipulations of various types, such as cut-and-paste and replay attacks.

Because VTun does not sequence number its blocks either explicitly or implicitly, any block can be replayed without detection. If we consider financial transactions, such as fund transfers, we see why this can be a devastating weakness.

Finally, VTun's security ultimately relies on a single, long-lived shared secret. As we've seen before, this represents another serious weakness because such keys are subject to physical compromise and because they allow an attacker to accumulate and analyze a large amount of ciphertext encrypted with the same key. This problem is exacerbated in VTun because the challenge/response protocol provides pairs of ciphertext and the corresponding plaintext, enabling known text attacks on the underlying encryption algorithm.

VTun's security is sufficiently weak that it shouldn't be used in circumstances that require anything more than the most casual security. We could use it as a sort of low-level cloaking protocol in situations where the data is of low value and active attacks are not a threat, but there are other, better protocols that share VTun's simplicity while delivering better security.

See [Gutmann 2003b] and [Etienne 2001] for further analyses of VTun's security.


Section 8.3. CIPE

8.3. CIPE

CIPE (crypto IP encapsulation) is another lightweight VPN that, like VTun, has some serious security problems. Unlike VTun, CIPE is implemented as a combination of a kernel module and a user-space daemon. Because of the kernel component, CIPE runs only on Linux and Microsoft Windows NT. Information and source code are available at the CIPE home page, <http://sites.inka.de/bigred/devel/cipe.html>.

We discuss CIPE 1.6, the latest version at the time of this writing. There are also two versions of the CIPE protocol. Version 3, which we discuss, tunnels IP datagramsthat is, it operates at the network layer. Version 4 operates at the link layer and can therefore be used to carry any type of interface-layer packet. The version 4 protocol is used mostly to build Ethernet bridges, and we will not discuss it further.

CIPE encapsulates encrypted IP datagrams in UDP datagrams, as shown in Figure 8.6.

Figure 8.6. CIPE Encapsulation

[View full size image]

This has an advantage over the VPNs that we built using SSL and SSH in Chapter 6 and Chapter 7, because CIPE tunnels will not have nested TCP connections that interfere with each other and affect throughput. Because the UDP header has unencrypted port fields (Figure 2.14), CIPE can interoperate with NAT/PAT.

Encrypting, UDP encapsulating, and sending and receiving IP datagrams are done in the kernel module, which provides a network device to which IP datagrams are routed. The network devices at the local and remote hosts serve as the endpoints of the tunnel.

The user-space daemon, ciped, controls the configuration, starting, stopping, and key-exchange protocol of the VPN. In addition, ciped can run a script when a VPN is brought up or torn down. This facility is useful for configuring routes and logging.

CIPE has two modes of key negotiation. The first uses a long-lived static key, defined in the configuration file, to encrypt and send a short-lived session key to its peer. The peer does the same, so two session keys are in use during the lifetime of the VPN. The key that one side sends is called the sending key; the key that it receives from its peer is called the receiving key. As the names suggest, an endpoint will encrypt its outgoing packets with the sending key and decrypt its incoming packets with the receiving key. The protocol specifies that the session keys should be used no longer than 15 minutes nor encrypt more than 232 packets. These are the standard precautions intended to deny an attacker a large amount of data encrypted with the same key.

In the second method of key negotiation, the peers use Diffie-Hellman to agree on a key that replaces the long-lived static key. This key is written into the configuration file in place of the static key, and the VPN is brought up as before. The Diffie-Hellman exchange is made under the management of the pkcipe tool, which also rewrites the configuration file after completing the Diffie-Hellman exchange.

Once the peers have negotiated the session keys, IP datagrams delivered to the CIPE device are encrypted, encapsulated in a UDP datagram, and sent to the peer.

Binary Packet Format

We've already seen that CIPE encapsulates IP datagrams by adding a header and footer and placing the result in a UDP datagram. Now we want to look more closely at the header and footer. Together with the IP datagram, the header and the footer make up the CIPE binary packet, as shown in Figure 8.7. The K bit is 0 if the static key was used to encrypt the packet and 1 if the session key was used. The K bit is necessary because no information other than the K bit and IV is visible to the receiver before the packet is decrypted. The rest of the first 64 bits are random data, with the further requirement that bits 131 must not be all 0s. The first 64 bits, including the K bit, are used as an IV for the block encryption algorithm.

Figure 8.7. The CIPE Binary Packet

[View full size image]

After the IP datagram itself, 0 to 7 random bytes are added to pad the packet to a size of 3 mod 8. The final 5 bytes comprise the P byte and 4 bytes of CRC-32. The P byte contains a 3-bit padding length field and a 2-bit packet type, as shown in Figure 8.8. The valid packet types are 00 for a data packet and 01 for a key-exchange packet. The other values are reserved.

Figure 8.8. The CIPE P Byte

[View full size image]

The padding bytes are weak random bytes generated with a linear congruential random number generator similar to the C library function rand and seeded with bits from the system clock. The IV is generated by first setting bits 031 to a counter, initially 0, and bits 3263 to random bytes, using the same random number generator used for the padding. The resulting 64-bit block is encrypted with the Blowfish algorithm, using a key generated for this specific purpose. The result of the encryption is used as the IV, with bit 0 replaced by the K bit.

This process will be repeated up to five times to get an IV that does not have all 0s in bits 131.

When the counter exceeds 32,767, a new key is calculated for the IV generation process. This key is merely 16 random bytes generated with the same linear congruential algorithm used for the padding and second half of the IV.

Key Negotiation

As the VPN is being brought up, both peers have invalid session keys, so they use either the long-lived static key from the configuration file or the Diffie-Hellman key negotiated by pkcipe for this invocation of the VPN. In either event, this key is used only until a session key is negotiated. The session keys are obtained by reading 16 bytes from /dev/urandom, the Linux high-entropy random number generator.

The random/urandom device gathers entropy from hardware events, such as keystroke timings and device interrupts. This entropy is used to generate high-quality random numbers. If the entropy pool becomes depleted, the urandom interface will supply random numbers that are theoretically vulnerable to cryptographic attack. No such attacks are publicly known, however, and the entropy pool is continually refreshed, so we can probably ignore this weakness for most applications. The random interface will block when there is not enough entropy, so the problem does not exist for it.

The peers negotiate the session keys by the exchange of key-exchange packets (Figure 8.9).

Figure 8.9. The CIPE Key-Exchange Packet

These packets are at least 64 and at most 320 bytes long. A variable amount of random padding is added after the timestamp in an effort to make the identification of key-exchange packets more difficult.

The three types of key-exchange packets are shown in Figure 8.10.

Figure 8.10. Key-Exchange Packet Types

Number

Type

Purpose

1

NK_REQ

requests that peer send new key

2

NK_IND

packet contains new key

3

NK_ACK

confirms receipt of new key

The typical key exchange involves the exchange of four packets. Each side informs the other of the session key it will use as a sending key; the peer receiving this key, its receiving key, acknowledges its receipt by sending an ACK packet. The exchange for one of the session keys is shown in Figure 8.11.

Figure 8.11. CIPE Key-Exchange Protocol

The other peer, the responder in Figure 8.11, initiates a similar exchange to negotiate the other session key. To the sender of an NK_IND packet, the packet contains a sending key; to the receiver of the packet, it contains a receiving key. The NK_ACK packet contains the CRC of the key whose receipt the peer is acknowledging.

If a peer receives a packet with the K bit set but does not have a valid receiving key, it can request its peer to send it a new session key with the NK_REQ packet. In this case, the exchange is like that shown in Figure 8.12.

Figure 8.12. Peer Requests a New Receiving Key

If the sender of an NK_IND packet does not receive an NK_ACK packet within the timeout period, it will send another NK_IND packet with a new key. Recall that key-exchange packets are encapsulated in UDP datagrams, so it's possible that either the NK_IND or the NK_ACK packet could be lost, requiring this resend.

After a peer sends 32,767 packets with a sending key, it invalidates the key and informs its peer of the new key by sending it an NK_IND packet. Similarly, after a key has been used for a specified amount of time10 minutes by defaultthe peer will invalidate the key and send its peer a new key. If a peer receives more than 65,534 packets with the same receiving key or more than twice the key-timeout period has elapsed for the receiving key, the peer will send an NK_REQ packet requesting a new key.

CIPE uses two mechanisms to avoid replay attacks on its key-exchange protocol. First, it remembers the last 256 CRCs from NK_IND packets and will rejectby not ACKinga key having a CRC in the list. A similar check is made for the CRCs in NK_ACK packets.

Second, CIPE places a timestamp in each key-exchange packet (see Figure 8.9). If the difference between the timestamp and the current time exceeds a configured maximum, CIPE will reject the packet. Because this feature requires that the system clocks of the two systems be more or less synchronized, its use is optionalspecifying a timeout of 0 seconds will disable it.

PKCIPE

Since version 1.5, CIPE has had the ability to negotiate its static key on the fly rather than using the long-lived key stored permanently in the configuration file. CIPE does this by means of the pkcipe utility, which negotiates a session-specific static key, using the Diffie-Hellman algorithm.

As does VTun, PKCIPE uses the OpenSSL libraries to handle encryption, random number generation, big-number arithmetic, and the Diffie-Hellman exchange. Also like VTun, PKCIPE does not use the SSL protocol but merely makes use of the cryptographic primitives supplied by the library.

The PKCIPE negotiation takes place over a TCP connection, so the protocol does not have to concern itself with reliability. The PKCIPE protocol accomplishes three main tasks:

  1. Negotiates a static key for this session

  2. Authenticates the peers to each other with RSA

  3. Negotiates session parameters

We will examine each of these functions as we discuss the protocol.

PKCIPE has its own packet format, as shown in Figure 8.13.

Figure 8.13. The PKCIPE Packet Format

[View full size image]

The first byte is called the marker and is always 0x2a. The length field is the total length of the type and data fields. Each byte of the length field is exclusive-ORed with 0x50.

The type field identifies the message type carried by the packet. Figure 8.14 shows the values that type can take. The data field carries the payload of the message and depends on the message type.

Figure 8.14. PKCIPE Message Types

Value

Name

Meaning

0

PKT_DEBUG

ignore, but log these messages

1

PKT_ERROR

a protocol error has occurred

2

PKT_DONE

protocol completed successfully

17

PKT_NONCE

nonce used for key generation

18

PKT_DHKEY

Diffie-Hellman public key

19

PKT_IDENT

host identification

20

PKT_SIGN

signature over certain packets

21

PKT_READY

CIPE started

22

PKT_OPT_REQ

option request

67

PKT_MAGIC

identifies the PKCIPE protocol version

The check field is either a 1-byte sum of the type and data fields (PKCIPE version 2) or a 20-byte SHA-1 hash of the type and data fields (PKCIPE version 3).

Figure 8.15 shows the first part of a typical PKCIPE exchange.

Figure 8.15. The PKCIPE Protocol

The PKT_MAGIC packet indicates the highest PKCIPE protocol version that the sender supports. The peers will use the lowest protocol version in these messages. The PKT_MAGIC message itself is sent using protocol version 2 so that either version of the protocol can understand it. The message data consists of an ASCII string of the form CIPE/03 vvvvv xxxxx *, where vvvvv is the PKCIPE program version, and xxxxx is a short description of the version. Notice that the C in CIPE serves as the message type.

Next, the peers exchange nonces. Each nonce is a random number of at least 8 bytes. After the Diffie-Hellman exchange, which comes next, the peers will combine these nonces with the Diffie-Hellman shared secret and use the result for key generation. The PKT_DHKEY messages contain the public keys (gx mod p) from which the peers derive the shared secret. PKCIPE uses a fixed group and generator for the Diffie-Hellman exchange, which are compiled into the PKCIPE binary.

At this point, the peers independently generate three keys. The peers will use two of these to encrypt the remainder of the PKCIPE protocol with RC4 (one key for each direction). The third key is the static key that CIPE will use in place of the long-lived static key from the configuration file.

The key generation is similar to that for TLS (Chapter 6). First, the peers calculate the four constants A0, . . . , A3, where

A0 = (NONCElocal [image] NONCEremote) || padding

Ai = H(secret, Ai-1) (i > 0)

The three keys are then

Ki = H(secret, Ai || A0) (1 [image] i [image] 3)

where NONCElocal and NONCEremote are the local and remote nonces, padding is enough nulls to pad the result of the exclusive-OR to 16 bytes, and H(x, y) is the SHA-1 HMAC of x and y.

Next, the peers identify and authenticate themselves to each other. The protocol exchanges for this are shown in Figure 8.16.

Figure 8.16. Identification and Authentication

At installation time, each peer generates an RSA key pair. The private key is kept locally, and the public key is provided to any peer that the local host might want to connect to. Each peer will send a fingerprint of its public key in the PKT_IDENT message to allow its peer to make a quick check that each side has associated the correct RSA key with its peer.

The PKT_IDENT message data has the form ffffffff iiii...i, where the ffffffff is the fingerprint of the sending peer's public key, and the iiii...i is an arbitrary string identifying the peer.

The "fingerprint" is actually a simple checksum of the modulus of the public key. The checksum is formed by grouping the bytes of the modulus in 4-byte sets, starting with the high-order bytes, and discarding any bytes remaining after the last 4-byte set is formed. These 4-byte sets are then exclusive-ORed together to form the 32-bit checksum.

On receiving the PKT_IDENT message, each side looks up its peer's public key, using the identification string, and verifies that the fingerprint is correct. If so, the peer will sign the PKT_DHKEY and PKT_IDENT packets that it sent and the PKT_NONCE packet that it received. The signature is generated using the RSASSA-V1_5-SIGN operation specified in PKCS #1 [RSA Laboratories 2002]. This signature is sent to the peer in a PKT_SIGN message.

At this point, both peers have identified and authenticated the other side and have generated a static key to use for this session. In the remainder of the protocol, shown in Figure 8.17, the peers negotiate options, start their respective ciped daemons, and terminate the TCP connection.

Figure 8.17. Final Step in the PKCIPE Protocol

With CIPE 1.6.0, the only option is the UDP address that the peer should send its CIPE messages to. This option is necessary because the peer's CIPE address can be different from its PKCIPE address. The address is sent in a PKT_OPT_REQ packet as a string of the form me=aaaa...a, where aaaa...a is the address the peer should use.

After a peer has finished with option negotiation, it will write the static key and other user options to a configuration file and start ciped. After ciped starts, the peer will send a PKT_READY message, telling the other side that it has started its side of the tunnel and that the other side should do the same. When the other side responds with its own PKT_READY, the peer will send a PKT_DONE message and disconnect. At this point, both sides of the tunnel have been started and will be ready for traffic as soon as they finish negotiating their session keys.

Control Messages

A CIPE endpoint can send its peer control messages as well as data. Figure 8.18 lists the seven control messages and their uses.

Figure 8.18. CIPE Control Messages

Value

Name

Use

0x70

CT_DUMMY

a no-op used for keep-alive purposes

0x71

CT_DEBUG

contains a debug message to be logged

0x72

CT_PING

echo request

0x73

CT_PONG

echo reply

0x74

CT_KILL

requests peer to exit

0x75

CT_CONFREQ

informs peer of sender's configuration

0x76

CT_CONF

response to CT_CONFREQ

Control messages are carried in key-exchange packets and except as noted later are encrypted. The CT_DEBUG and CT_KILL messages carry a string that the peer will log. The CT_PING and CT_PONG messages are a method of ensuring that a peer is still reachable. The CT_PING message carries a string, which the peer copies to a CT_PONG message and returns to the sender of the CT_PING.

The CT_CONFREQ message informs the peer of an endpoint's fixed configuration. Figure 8.19 shows the contents of the CT_CONFREQ and CT_CONF messages.

Figure 8.19. CIPE Configuration Message Data

Offset

Value

Meaning

03

filler

ignored

48

CIPE

the ASCII name of the protocol

9

3 or 4

CIPE protocol version

10

"b" or "@"

type of encryption

1112

major/minor version number of software

13

0 or 1

broken-key interpretation flag

Except for the type of encryption and broken-key interpretation flag, the items in Figure 8.19 are self-explanatory. By default, CIPE uses Blowfish encryption, in which case the byte at offset 10 will be a "b." CIPE can also be compiled to use the Linux Crypto API for those kernels that support it. In that case, the byte at offset 10 is a "@."

An earlier version of CIPE had a bug in the code that read and interpreted the static key. The code gave the hex digits a through f the values 1 through 6 rather than 10 through 15. The flag at offset 13 is 0 if CIPE was compiled with the broken-key interpretation code and 1 otherwise.

When a peer receives a CT_CONFREQ message, it checks the configuration against its own to make sure that they agree and to warn the user if not. The receiver of the message answers with a CT_CONF message containing its configuration.

The CT_CONFREQ and CT_CONF messages are sent unencrypted because they contain information about what encryption algorithm should be used and because they contain information that the peers should have before it is known whether they have matching static keys. CIPE signals the unencrypted packet by having an IV that is all 0s, including the K bit.

CIPE Security

CIPE was developed when Intel 80386 processors and 2400 bps modems were common hardware, and this fact is reflected in its design. We see this most strikingly in the binary packet format, where several design decisions were made with the limited processing power and bandwidth of the hardware in mind.

The first thing we notice is the use of a CRC-32 checksum instead of a MAC. As we saw before in Chapter 7, this is a serious weakness. We also notice that the CRC really is just a checksum, and not a weak MAC, because no key is associated with it. Although there are no known exploits of this weak integrity checking, the method of [Futoransky, Kargieman, and Pacetti 1998] could probably be used to devise one.

The next problem with the binary packet is the limited padding. Because the P byte (Figure 8.8) uses only 3 bits for the length of the padding, we are restricted to a maximum of 7 bytes. This has some implications. First, it means that we must use a 64-bit block size for our block encryption. As discussed in Chapter 3, most experts agree that a 64-bit block size is too small. In particular, it means that AES and other modern block ciphers are not available for use with CIPE.

Second, it means that it is difficult to hide the true message size and that the VPN is therefore subject to at least limited traffic analysis. For example, we know that key-exchange packets are between 64 and 320 bytes long. If the other traffic in the tunnel has either shorter or longer packets, it is possible to identify and interfere with the key-exchange packets.

Another serious concern with the CIPE protocol is the lack of sequence numbers, which renders CIPE susceptible to replay, deletion, and insertion attacks. This lack is especially serious if the key-exchange packets can be identified, as discussed earlier. In that case, an attacker can prevent key updates; force the use of an old, compromised key; or perhaps even manipulate keys in transit. To some extent, CIPE protects against these attacks with the timestamps and cached key CRCs, but these safeguards aren't foolproof. In any event, we still have the concern that critical packets, such as fund transfer requests, can be replayed.

The decision to omit sequence numbers from CIPE is a consequence of the use of UDP as the transport protocol. As we've seen, this is preferable to using a reliable protocol, such as TCP, because we don't get two reliable protocols competing with each other and adversely affecting throughput. On the other hand, using an unreliable protocol means that packets, and thus their sequence numbers, can be lost or delivered out of order. It's easy to see how this can make using sequence numbers to enhance the security of the protocol difficult. We should note, however, that tinc and OpenVPN, which use UDP encapsulation, and IPsec, which operates at the IP layer, also have unreliable delivery and use sequence numbers to prevent replay and insertion attacks. We will see how this works later in this chapter and in Chapter 11.

Although CIPE is probably more secure than VTun, we should exercise careful consideration before deploying it in any situation that requires serious security. In the absence of active attacks, CIPE appears to provide reasonable privacy, so it could find useful work as a data-cloaking protocol for low-value data transfer. It probably should not be used to carry high-value data or in situations in which active attacks are likely. As always, we must consider the threat model that we are attempting to protect against. There is a further discussion of CIPE security in [Gutmann 2003b].


Section 8.4. Tinc

8.4. Tinc

Next, we consider tinc, a system that can provide a VPN network rather than just an encrypted tunnel between two hosts or networks. We can think of a tinc VPN network as a graph of nodes, such as that shown in Figure 8.20, where the edges between the nodes are encrypted and authenticated tunnels. Typically, each node serves as a VPN gateway for one or more subnets behind it. A node could also be a stand-alone host participating in the VPN network. We examine version 1.0.3 of tinc.

Figure 8.20. A Typical Tinc Network

Routing within the VPN network is handled by tinc itself. For example, if node A wants to send a packet to node B, it can send the packet directly through the encrypted tunnel between it and node B. On the other hand, if node A wants to send a packet to node C, it must first send it to node E through the tunnel between nodes A and E. Node E will decrypt and then reencrypt the packet for the tunnel between it and node C and send it through the tunnel to node C. The nodes exchange connectivity information and calculate routing maps in a way reminiscent of OSPF (Chapter 2). This information is continually updated as nodes join or leave the network or become unreachable.

Architecturally, tinc is similar to VTun in that it is implemented entirely in user space. As with VTun, outbound packets are read from the stack, and inbound packets are written to the stack by means of the tun/tap device.

Tinc uses two channels for each VPN: a UDP-based tunnel to carry the payload data of the VPN and a TCP-based connection for the so-called metaconnection that is used to carry control data, such as routing and key-exchange messages. The tinc daemons communicate with each other over the metaconnection, using the tinc metaprotocol.

As with the other lightweight VPNs we've discussed, tinc can operate at either the IP or link layer. When operating at the IP layer, tinc is restricted to carrying IP datagrams. The link-layer mode is used to create Ethernet switches and hubs. We consider only the IP mode, but the link-layer mode is similar.

The Tinc UDP Tunnel

The tinc data-bearing channel follows the now familiar pattern of UDP encapsulation of IP datagrams, as shown in Figure 8.21 for the typical case of a TCP segment.

Figure 8.21. Tinc Encapsulation

[View full size image]

As indicated in the figure, tinc can compress its payload data, as well as encrypt and authenticate it.

If we take the point of view of the encapsulating UDP datagram, we see that the tinc binary packet comprises the tinc header, payload data, and tinc footer. The tinc header is a 32-bit packet sequence number. The footer is some or all of an HMAC. Figure 8.22 shows the tinc binary packet format with these features exposed.

Figure 8.22. The Tinc Binary Packet

[View full size image]

The sequence number has two purposes. First, it serves the obvious function of preventing replay attacks: Any packet having the same sequence number as a previously received packet is dropped. This task is more difficult than it might seem, because packets can arrive out of order. We'll examine the tinc sequence number-checking mechanism shortly.

The second, less obvious, function of the sequence number is to serve as an IV if tinc is using a block cipher. The sequence number isn't exclusive-ORed into the first block as a traditional IV would be but rather serves as the first 32 bits of the first block. This means that even if two packets have the same data, they will not encrypt to the same ciphertext. This is obvious for the first blocks because the first 32 bits will differ. Subsequent blocks use normal CBC-mode encryption, so they will differ because the first blocks do.

Tinc also uses a traditional IV for the first block, but it is set at key-generation time and is the same for every packet. Thus, it is not useful by itself in hiding identical packets, but because the sequence number changes for every packet, we get the effect of traditional CBC mode.

When the maximum sequence number is reached, tinc generates a new session key, so a sequence number is never reused with the same key. This is important because it prevents an attacker from replaying a packet after the sequence numbers have wrapped. It also limits the amount of data that tinc will encrypt with a single keyanother important step in preventing an attack on the cipher, as we've seen.

The HMAC field is formed by taking a standard HMAC (SHA-1 by default) of the sequence number and data fields and using some or all of the resulting bits. By default, the upper 32 bits are placed in the HMAC field, but this is a user-settable parameter.

Sequence Number Checking

As we mentioned earlier, the use of sequence numbers in a protocol that uses an unreliable transport mechanism is challenging. We can't simply check that the sequence number is one more than that of the last packet, because packets can be lost or delivered out of order. Because packets can be lost, we don't want a missing sequence number to cause us to tear down the tunnel, as we would with SSH or SSL. What we do want is to ensure that each sequence number is seen at most once.

Keeping a list of each sequence number that it's seen isn't practical, of course, so tinc confines its attention to the last 128 sequence numbers and for each one remembers whether it has received a packet with that sequence number. When tinc receives a new, higher sequence number, it forgets the oldest sequence numbers, remembering only the new sequence number and the 127 that come before it. In other words, tinc uses a sliding window that is 128 sequence numbers long, with the right-hand edge of the window at the last sequence number received.

Any packet with a sequence number to the left of the window is dropped, as is any packet with a sequence number lying within the window that tinc has seen before. When tinc receives a packet with a sequence number to the right of the window, it slides the window to the right, forgetting about the sequence numbers that fall off the left-hand edge, whether or not tinc has ever received them.

The Tinc Metaprotocol

As we noted above, tinc sends all its control messages over a separate TCP connection, using the tinc metaprotocol. The messages themselves have a simple line-oriented ASCII format. They would be human readable except that tinc encrypts them by default.

The basic format of a message is

<type> <parameters>

where <type> is an ASCII numeric code specifying the message type, and <parameters> represents one or more parameters. The message types are shown in Figure 8.23.

Figure 8.23. Metaprotocol Message Types

Value

Message

Type Purpose

0

ID

host identification

1

METAKEY

keying material for metaconnection

2

CHALLENGE

authentication challenge

3

CHAL_REPLY

reply to authentication challenge

4

ACK

acknowledgment of correction authentication

5

STATUS

status string for logging

6

ERROR

error notification

7

TERMREQ

request to terminate connection

8

PING

keep-aliveecho request

9

PONG

keep-aliveecho reply

10

ADD_SUBNET

add a subnet to graph

11

DEL_SUBNET

delete a subnet from graph

12

ADD_EDGE

add a node (host) to graph

13

DEL_EDGE

delete a node (host) from graph

14

KEY_CHANGED

node has changed its key

14

REQ_KEY

request a node's key

15

ANS_KEY

reply to key request

16

PACKET

TCP data packet length and data

When one tinc daemon connects to another, both sides send their peer an ID message of the form

ID tinc_host_name protocol_version

When a peer receives this message, it checks that the sender is a valid host and that both sides are using the same protocol version. If so, the peer responds with a METAKEY message of the form

METAKEY cipher_ID digest_ID digest_len compression_ID random_string

The cipher_ID and digest_ID are the OpenSSL cipher and digest typesBlowfish and SHA-1 by defaultthat this node will use for the data channel and also to encrypt the metachannel. The digest_len tells the peer how many bits of the HMAC this host will send with data channel messages.

Tinc can perform optional compression on data channel packets. The compress_ID parameter indicates what type of compression to use: 0 for none, 1 (fast ZLIB)9 (best ZLIB), 10 (fast LZO) and 11 (best LZO). The default is no compression.

The random_string is a hex-encoded string of random bits that are encrypted using the recipient's public RSA key. The bit string is the same length as the modulus of the public key and has the most significant bit set to 0 so that it will have a value less than the modulus of the key, as required by the RSA algorithm. These random bits are used to generate the session key and IV used for metachannel encryption; the metachannel has no integrity checking. After sending the METAKEY message, the node will encrypt all further messages on the metachannel.

The peer receiving a METAKEY message sets the encryption parameters for the incoming connection and responds with a CHALLENGE message of the form

CHALLENGE random_string

The random_string is again the hex-encoding of a random bit string the same size as the modulus of the receiver's public key. The receiver hashes the challenge, using the previously negotiated digest method, and returns the result to the challenge's originator in a CHAL_REPLY message of the form

CHAL_REPLY hash

Up until this point, the sender of the CHALLENGE could not be sure of the identity of its peer, even if it has received a METAKEY message from it. The CHAL_REPLY message is the first encrypted message that it receives from its peer. If the hash is correct, the receiver of the CHAL_REPLY message can be sure that its peer knows the session key used to encrypt the challenge and therefore that it had possession of the RSA private key corresponding to the RSA public key that the receiver of the CHAL_REPLY message used to encrypt the session key.

Once it validates the hash, the receiver of the CHAL_REPLY message responds with an ACK message of the form

ACK port estimated_weight options

The port parameter indicates the port that the node should send the data channel UDP datagrams to. The estimated_weight parameter is an estimate of the latency between the peers. This parameter is used to weight the edges when constructing a minimal spanning tree used for routing broadcast messages, and has three possible options:

IndirectData | A flag indicating that the node is willing to accept connections from nodes that it has not explicitly authorized.
TCPOnly | A flag indicating that the data channel should use TCP encapsulation rather than UDP encapsulation. As we've seen previously, this is usually a bad idea.
PMTUDiscovery | A flag indicating that tinc should try to discover the path MTU to the sending node.

When a node receives the ACK message, it sends its peer a list of all nodes and subnets that it knows about, using the ADD_EDGE and ADD_SUBNET messages that we discuss later. The peer uses this information to update its routing graph. The node will also broadcast information about its new peer and connection to all the hosts in its routing graph. Finally, the peer updates its own routing graph with the connection to its new peer.

A typical authentication protocol exchange is shown in Figure 8.24. The two sides start the protocol independently and then react to the messages from their peer, so the exact flow may differ slightly from that shown in the figure.

Figure 8.24. The Tinc Authentication Protocol

As we've seen, at the end of the authentication protocol, each tinc node will inform its peer of all the other nodes and subnets that it knows about. As other nodes enter and leave the VPN network, tinc nodes will likewise inform their peers about the event. A node informs its peer about the nodes it knows about with the ADD_EDGE message. This message has the form

ADD_EDGE random from to to_addr to_port options weight

where random is some random bytes added as a salt to make known plaintext attacks more difficult. The from parameter is the name of the source node for this connection, and the to parameter is the corresponding destination node for the connection. The to_addr and to_port parameters are the IP address and port of the destination node that the UDP datagrams should be sent to. The options and weight parameters are the same as they were for the ACK message.

Along with the ADD_EDGE message, a node will usually send one or more ADD_SUBNET messages that inform the other nodes of subnets in the VPN network and how to reach them. These messages have the form

ADD_SUBNET random owner_name IP_addr/netmask

As before, the random parameter is some salt added to make cryptanalysis more difficult. The owner_name parameter is the name of the node that owns the subnet that is being added, and the IP_addr/netmask parameter is the IP address and subnet mask of the subnetwork.

Corresponding to the ADD_EDGE and ADD_SUBNET messages, there are DELETE_EDGE and DELETE_SUBNET messages of the forms

DELETE_EDGE random from to
DELETE_SUBNET random owner_name IP_addr/netmask

where the parameters are the same as those for their corresponding ADD_* messages.

Tinc has three messages dealing with key management. If node A wishes to send an encrypted datagram to node B, it must know what session key node B is using. The nodes don't inform each other of their session keys until asked, so the first time node A wants to send a datagram, it won't have a valid key. Therefore, node A will send a REQ_KEY message to node B, asking for its session key. The REQ_KEY message has the form

REQ_KEY from to

where the from parameter is the name of the node requesting the key, and the to parameter is the name of the node from which it is requesting the key.

When a node receives a REQ_KEY message, it responds with an ANS_KEY message of the form

ANS_KEY from to key cipher_ID digest_ID digest_len compression_ID

where from is the name of the owner of the key, to is the name of the node requesting the key, and key is the key itself encoded as a hex string. The cipher_ID, digest_ID, digest_len, and compression_ID are the same as they were in the METAKEY message.

When a node's session key expires because of age or because the sequence numbers are about to wrap, it will generate a new key and notify the rest of the nodes by sending a KEY_CHANGED message. This message has the form

KEY_CHANGED random name

where random is a random salt value, and from is the name of the node whose key has changed. When a node receives this message, it will invalidate its session key for the sending node so that the next time it needs to send that node a datagram, it will first send a REQ_KEY message to get the new key.

Two messages are available to cause the teardown of a connection between two nodes. The TERMREQ message is for an orderly teardown, and the ERROR message is for a teardown caused by an error. These two messages have the forms

TERMREQ
ERROR error_code error_string

where error_code is a numeric code indicating the error, and error_string is a human-readable string that gets logged by the receiver.

A node can cause its peer to log debugging information by sending it a STATUS message. The STATUS message is similar to the ERROR message but does not cause the teardown of the connection between the peers. It has the form

STATUS status_code status_string

where status_code is a numerical status code, and status_string is the corresponding human-readable string for the log.

Recall that tinc has the ability to use TCP encapsulation. When this option is in effect, tinc sends the encrypted datagrams over the metachannel in a PACKET message. This message has the form

PACKET length data

where length is the number of bytes of data that follow, and data is the encrypted datagram.

Finally, tinc has two messages that it uses to test for connectivity. These are the PING and PONG messages, which have the forms

PING
PONG

When a node wants to ensure that its peer is still alive, it sends it a PING message. The peer will respond with a PONG message. If the sender of the PING message does not receive the PONG, it will mark the connection down.

Tinc Security

As with the other VPNs we have studied in this chapter, tinc uses OpenSSL to provide encryption primitives but does not use the SSL protocol itself. Tinc can use any of the encryption algorithms or hash methods that OpenSSL provides, so a tinc user has a large variety of crypto systems available. By default, tinc uses Blowfish and SHA-1, but algorithms with larger block and key sizes, such as AES, are also available.

Let's first look at the authentication protocol. After the ID message, the peers exchange the keys they will use for metaprotocol encryption. There are two criticisms of this procedure. First, each side determines its transmit key by itself, violating the rule that neither side should specify a key completely. On the other hand, the key is used only to transmit data from the node that specified it, so a node can't be tricked into using a weak key by its peer, which is what the rule is meant to prevent. That leaves open the possibility that one peer has a weak random number generator, but because both sides use the OpenSSL random number generator, their results will most likely be similar.

The tinc developers recognize that having one side completely determine the key is a potential weakness, and they indicate that they plan to fix this in version 2.

The second criticism is that the key is encrypted as a raw bit string without any PKCS #1 [RSA Laboratories 2002] padding or other protection. This is also probably safe because the key is a completely random-bit string of the same length as the RSA key modulus. This means that the encrypted key has no structure that an attacker can exploit and that the message is large enough that the trivial decryption we discussed in Chapter 3 is not possible. Because the bit string is completely random, the receiving node can do no verification of its value, so the receiving node will not act as an oracle for active attacks other than for a timing attack that we discuss next.

Tinc installations using older versions of the OpenSSL library are subject to timing attacks on the RSA key, such as those described in [Brumley and Boneh 2003]. These are adaptive chosen text attacks that measure the time to decrypt specially formed messages and use the results to infer the RSA private key. Newer versions of the OpenSSL library perform an operation called RSA blinding, which prevents these attacks. The details are in the Brumley and Boneh paper.

As we've seen, the UDP data channel refreshes its keys after they have been used for a certain amount of time or have been used to send more than a fixed number of messages. This is not the case with the metachannel: The same two keys are used for the life of the connection between two nodes. Although the metachannel will, in general, have much less traffic than the data channel, having long-lived keys is never a good idea.

Again, the tinc implementers recognize this weakness and intend to resolve it in version 2.

Finally, although the metachannel is encrypted, there is no integrity checking. That is, the packets don't have sequence numbers and aren't protected by a MAC. This means that the metachannel traffic is vulnerable to insertion, deletion, cut-and-paste, and replay attacks.

[Gutmann 2003b] criticizes the tinc data channel for using predictable IVs in the form of the sequence numbers and a too small HMAC. The problem with predictable IVs is that they are vulnerable to Rogaway's attack (Chapter 7), but the sequence numbers are part of the data in the packet and are not exclusive-ORed into the block in the normal CBC mode manner. Therefore, the predictability of the sequence numbers does not appear to cause a problem.

The tinc implementers indicate that they are planning to add a conventional IV and move the sequence number out of the ciphertext in a later tinc version.

Tinc's default configuration uses the first 4 bytes from the HMAC calculation for the MAC. RFC 2104 [Krawczyk, Bellare, and Canetti 1997] recommends using the greater of half the bits of the HMAC output or 80 bits. From this perspective, the 32 bits that tinc uses is too small. On the other hand, tinc allows us to specify a larger number of bits, and we should probably do so.

The final problem with the data channel is that the same key is used for encryption and for the HMAC. Cryptographers generally agree that this is a poor practice and can potentially leak information to an attacker.

In summary, tinc appears to have reasonably good security. The problems that we discussed do not appear to be fatal, and the developers have already announced plans to address many of them. We should probably ensure that we have an up-to-date version of OpenSSL ( [image] 0.9.7b) installed before deploying tinc, in order to avoid the timing attacks that we discussed.


Section 8.5. OpenVPN

8.5. OpenVPN

Our final lightweight VPN is OpenVPN. Although OpenVPN shares many of the features of the other lightweight VPNs that we have studied, it makes more intelligent use of SSL than the others do and is consequently more secure. We examine OpenVPN version 1.6.0.

Architecturally, OpenVPN is superficially similar to tinc and VTun in that it is a user-mode program that communicates with the TCP/IP stack through the TUN/TAP interface. Running as a user program brings the usual benefits of portability and easy maintenance that we have seen with VTun and tinc. Like tinc, OpenVPN multiplexes two channels onto the VPN: a data channel that carries the users' IP datagrams and a control channel that handles such protocol chores as key negotiation and configuration.

OpenVPN encapsulates both the control and data channels in UDP datagrams. It uses the same ports for both channels, so a given UDP datagram can contain either a control or a data channel message. Because OpenVPN uses the TLS protocol for authentication and key exchange and because TLS requires a reliable transport layer, OpenVPN adds a reliability layer to the control channel, while maintaining best-effort delivery on the data channel. This ensures that TLS gets the reliability that it requires but that there will not be competing reliability layers on the data channel, so the interference we experienced with SSL (Chapter 6) and SSH (Chapter 7) VPNs will not occur.

As with the other VPNs we have looked at in this chapter, OpenVPN can carry either IP datagrams or Ethernet framesthat is, it can operate at either the IP layer or the data link layer. We shall restrict our attention to its use in carrying IP datagrams, but the details of the other mode are similar.

The OpenVPN Security Models

OpenVPN can operate using either of two security models. Each of these models has its own advantages and disadvantages, but as we shall see, only one of the models is appropriate in situations requiring more than casual security. We briefly describe the two models in this subsection, but reserve our detailed analyses for the more secure model.

In the first model, called the static key method, the two peers use preshared keys for encryption and authentication. These keys are agreed to and configured on each peer prior to starting the VPN. This means, of course, that some other secure method must be used to inform the peers of these keys.

By default, there are two keys: one for encryption/decryption and one for the authentication HMAC. In this case, both peers use the same two keys. It is possible, and more secure, to configure OpenVPN to use four keys: Each peer has an HMAC receive key, an HMAC send key, an encrypt key, and a decrypt key. That is, each peer has a set of keys for sending and another set of keys for receiving. This has the advantage of making key compromise more difficult and of limiting the damage if a single key is compromised.

Regardless of whether two or four keys are used, we should be wary of this methodwe have seen the disadvantages of using preshared keys many times already. The same keys will be used for the life of the VPN and indeed for every invocation of the VPN until they are manually changed and the VPN is restarted. Although using a different set of keys in each direction can slow the accumulation of data encrypted with a single key, all it can do is slow it. Eventually, the data accumulates and the preshared keys become more vulnerable. Once a key is discovered, all the data transmitted in any VPN invocation that used that key can be read.

The purported advantage of the static key method is that the configuration is easier. The VPN administrator needn't bother with certificates or certificate authorities, as required for the second method. Still, the administrative overhead of using certificates is quickly amortized if the administrator is setting up multiple VPNs. At the same time, the administrative overhead of dealing with static keys grows as additional VPNs are configured. For these reasons, the use of the static key method might be justified for a short-lived, ad hoc VPN but should be avoided for general use.

The second method, called the TLS method, uses the SSL protocol to authenticate each VPN endpoint to its peer and to exchange keys and other control information. In this method, OpenVPN establishes an SSL/TLS session with its peer for the control channel. During the authentication phase, the peers exchange certificates signed by a mutually trusted CA. As we saw in Chapter 6, this assures both sides that they are talking to their intended peer and thus prevents man-in-the-middle attacks.

Once authentication completes and an SSL session is established between the peers, OpenVPN uses the connection to negotiate session keys for the data channel. The administrator can configure OpenVPN to renegotiate these keys, based on any combination of bytes transmitted, packets transmitted, or time. This prevents the accumulation of text encrypted with the same key and also provides perfect forward secrecy: The compromise of a given key does not affect data transmitted before or after its use.

The TLS method provides very robust authentication and secure key exchange. Except for the short-lived VPNs that we discussed above, this method should be used exclusively. We limit the rest of our discussion to the TLS method and do not consider the static key method further.

The OpenVPN Data Channel

As we mentioned earlier, OpenVPN provides a best-effort data channel that uses UDP datagrams as its transport protocol.

OpenVPN can optionally use a TCP connection instead of UDP datagrams. Although this is convenient in certain circumstances, it reintroduces the problem of competing reliability layers and should be avoided when possible.

With UDP, we get the familiar encapsulation, shown in Figure 8.25, that we've seen before.

Figure 8.25. The OpenVPN Data Channel Encapsulation

[View full size image]

OpenVPN splits the payload header into two parts: the packet header, which identifies the type of packet and keying material, and the data payload header, which contains authentication, IV, and sequence number fields for the data packet.

Figure 8.26 shows the packet header for both (A) TCP and (B) UDP encapsulation. The packet length field that appears in the TCP version indicates the length of the following packet. This field is not needed for UDP, because UDP is a packet-oriented protocol, whereas TCP is a stream-oriented protocol (see ETCP, Tip 6). The op code field identifies the type of packet. Figure 8.27, shows its possible values.

Figure 8.26. The OpenVPN Packet Header

[View full size image]

Figure 8.27. OpenVPN Op Codes

Value

Op Code

Meaning

1

P_CONTROL_HARD_RESET_CLIENT_V1

initial type 1 key from client

2

P_CONTROL_HARD_RESET_SERVER_V1

initial type 1 key from server

3

P_CONTROL_SOFT_RESET_V1

new key

4

P_CONTROL_V1

control channel packet

5

P_ACK_V1

ACK

6

P_DATA_V1

datachannel packet

7

P_CONTROL_HARD_RESET_CLIENT_V2

initial type 2 or greater key from client

8

P_CONTROL_HARD_RESET_SERVER_V2

initial type 2 or greater key from server

The key ID field identifies the type of key used for this packet. We will examine this feature shortly.

Note from Figure 8.25 that the encryption and authentication extend part way into the data payload header. The exact structure is made clear in Figure 8.28, which combines the data payload header and payload into the OpenVPN data packet.

Figure 8.28. The OpenVPN Data Packet

[View full size image]

The HMAC field is a standard SHA-1 or MD5 based HMAC. As indicated in the diagram, this field authenticates the payload, packet ID, and IV. The IV is a randomly generated initialization vector for CBC-mode encryption.

In addition to CBC mode, OpenVPN supports the cipher feedback (CFB) and output feedback (OFB) modes, which require an IV. For more information on these modes, see [Dworkin 2001] or [Menezes, Oorschot, and Vanstone 1996].

The IV will usually be either 64 or 128 bits long.

The packet ID field is used as a sequence number to prevent replay attacks. Open-VPN maintains a sliding window of these sequence numbers and rejects a packet if its sequence number is to the left of the window or is within the window but previously received. When OpenVPN receives a packet with a sequence number to the right of the window, the window is slid to the right so that its right edge is at the new sequence number. This sliding-window mechanism is similar to the one we saw previously with tinc.

In addition to the sliding window, OpenVPN applies a time test and rejects out-of-order packets that are received more than t seconds after any packet containing a higher sequence number. The t parameter is configurable with a default value of 15 seconds. The width of the window is also configurable, with a default of 64 sequence numbers.

Figure 8.28 shows the packet ID as 32 bits, its size when CBC mode is in use. When CFB, OFB, or static key mode is in use, its size will be 64 bits. In CFB/OFB mode, these 64 bits, which are the concatenation of a timestamp and an incrementing counter, are contained in the IV as a space-saving optimization.

As we can see, the OpenVPN data channel precisely meets our requirements for a VPN: an encrypted and authenticated tunnel between two networks or hosts. As we'll see when we discuss security, the data channel is well engineered and does not have any apparent exploitable security weaknesses. It is, in fact, closely modeled on the IPsec ESP (Chapter 12) protocol and takes advantage of the lessons learned in the development and deployment of that protocol.

The Ping and OCC Protocols

In addition to user traffic, the data channel carries a limited amount of control information. OpenVPN can be configured to have the nodes send keep-alive messages and tear down or restart the VPN if they don't receive traffic for a specified time. Although OpenVPN refers to the keep-alive messages as ping packets, they are not pings in the ICMP sense; rather, if a node has not sent traffic for a specified time, it will send its peer a ping. On receipt of the ping, the peer will reset its packet receive timer and discard the packet. As we see from Figure 8.27, there is no ping message op code. Instead, the ping packets are sent as normal data channel packets with a unique byte sequence.

Note that the protocol requires only that each node ensure that it not go too long without sending traffic on the data channel. If a node does not receive traffic within the timeout interval, it can, depending on configuration, restart or tear down the VPN. A node expects no response to a ping packet and will not even know whether its peer received it.

During tunnel initialization, the nodes exchange configuration information, using the OCC protocol. As with the ping packets, these messages are delivered on the data channel and are distinguished from normal traffic by a prefix consisting of a unique byte sequence. The general format of these messages is shown in Figure 8.29.

Figure 8.29. The OpenVPN OCC Message Format

[View full size image]

The OCC magic field is a 16-byte unique sequence used to identify OCC packets. It's required because data channel packets do not have a message type field. The OCC op code field indicates the type of OCC message. The currently defined op code values are shown in Figure 8.30.

Figure 8.30. OCC Protocol Op Codes

Value

Op Code

Meaning

0

OCC_REQUEST

request for peer's option string

1

OCC_RREPLY

option string in response to OCC_REQUEST

2

OCC_MTU_LOAD_REQUEST

request for peer to send a big packet for MTU measurement

3

OCC_MTU_LOAD

response to OCC_MTU_LOAD_REQUEST

4

OCC_MTU_REQUEST

request for peer to send the size of largest packet received

5

OCC_MTU_REPLY

response to OCC_MTU_REQUEST

The optional OCC data field contains any additional data that the OCC message requires. For example, in the OCC_REPLY message, the OCC data field contains the node's option string.

The Control Channel

As we've seen with SSL, SSH, and the other lightweight VPNs, two of the most difficult parts of providing a secure data channel are key management and peer authentication. Errors in either of these two services can render the data channel insecure, no matter how well engineered the channel itself is. In this subsection, we see how OpenVPN handles these important aspects of the VPN.

One strength of OpenVPN is that it uses the SSL/TLS protocol for peer authentication and key management. Because the SSL protocol has undergone years of development and intense study, experts generally consider it secure, and OpenVPN is able to leverage this security to make its VPN secure as well.

Figure 8.31 shows the format of control channel packets.

Figure 8.31. The OpenVPN Control Channel Packet

[View full size image]

The session ID field is a 64-bit random number used to identify the VPN session. As we've seen with other protocols, each side has its own session ID for the VPN, and it is the sender's session ID that appears in this field.

The optional HMAC field is used to help prevent denial-of-service attacks. When present, this field authenticates the entire packet and allows a node to drop a bogus packet without expending any resources in processing it. It also prevents a bogus packet from reaching the SSL layer, where it could probe for weaknesses or potentially cause the leakage of information. This field is present only when the --tls-auth option is specified.

The packet ID field is used to prevent replay attacks. It plays the same role it does in data channel packets. When the TLS method is being used, this field is 32 bits; otherwise, it is 64 bits.

The ACK buffer is used by the reliability layer to acknowledge a peer's packets. The ACK buffer length field is a single byte that indicates how many acknowledgments are in the buffer. If the length is 0, the ACK buffer field is not present. When greater than 0, the length contains the number of 32-bit message sequence numbers that are in the buffer. At the end of the ACK buffer is the peer's session ID for this VPN. The peer uses this session ID to tie the acknowledgments to a particular VPN session. This field is present only when the length is nonzero.

If the op code for this packet is P_ACK_V1, the ACK buffer is the last field in the packet. When the op code is P_CONTROL_V1, the message sequence number field, which is the sequence number used by the reliability layer, and the TLS payload field, which contains normal SSL data records, are also present.

When the VPN starts up, the peers execute the normal SSL client authentication handshake (Chapter 6), where each side presents its certificate to its peer. After the authentication, both sides know that they are talking to the proper peer and have a secure SSL channel on which they can exchange keying material for the data channel.

There are two possible key-exchange messages. When the peers are using key method 1, as signaled by one of the V1 hard reset op codes in Figure 8.27, they use the message format in Figure 8.32.

Figure 8.32. The OpenVPN Key-Exchange Message (Key Method 1)

[View full size image]

The cipher key length field contains the length of the cipher key field, which contains a randomly generated key that the receiving peer should use as a decrypt key. Similarly, the HMAC key length field contains the length of the HMAC key field, which contains a randomly generated key that the receiving peer should use as the key to authenticate incoming packets. Note that there will be four keys: two from each peer. Again, this type of exchange is not ideal, because each of the keys is entirely determined by a single node.

The last field is a null-terminated option string. This option string must match the local option string, ensuring that the two peers are configured identically.

The second key method is more robust than the first. Each side contributes keying material that both sides use to derive the actual keys. When key method 2 is used, as signaled by one of the V2 hard resets in Figure 8.27, the peers exchange keying material, using the message shown in Figure 8.33.

Figure 8.33. The OpenVPN Key-Exchange Message (Key Method 2)

[View full size image]

As we see from the figure, the message starts out with 4 bytes of 0, followed by the 1-byte key-method field. Currently, this field will always be a 2, indicating key method 2, but having the field allows for the additional key methods in the future.

The premaster secret field is 48 bits of random data generated by the client. This field serves the same purpose as the identically named field in SSL: providing keying material from which a master secret can be generated. The premaster secret field is not present in the server's key-exchange packet.

The two fields random 1 and random 2 are also used in the key-generation process. They are each 32-bit random data. Because each side contributes two random fields, neither side can completely determine any of the keys.

The option string length field contains the length of the null-terminated option string. As in key method 1, the peers use this string to verify that they are configured identically.

The user name length field contains the length of the null-terminated user name field. Similarly, the password length field contains the length of the null-terminated password field. The user name and password are used when OpenVPN is run through an HTTP (Hypertext Transfer Protocol) proxy, and the proxy requires authentication. These fields are optional and are not present unless we are using an HTTP proxy.

The key-generation process is closely modeled on the method that TLS uses. First, both sides generate the master secret by concatenating the string OpenVPN master secret, the client's random 1, and the server's random 1, and using the result and the premaster secret as input to an HMAC calculation:

PRF(premaster secret, OpenVPN master secret || client random 1 || server random 1)

The PRF function takes the MD5 and SHA-1 HMACs of its arguments and exclusive-ORs the results.

The details of PRF are a little more complicated than indicated here. The PRF function first splits the secret in two and uses half for the MD5 HMAC and half for the SHA-1 HMAC. The required number of output bits is obtained by feeding the seeding material back into the HMACs repeatedly.

Once the peers have the master secret, they generate the four keysencrypt, decrypt, authenticate in, authenticate outby concatenating the string "OpenVPN key expansion", the client's random 2, the server's random 2, the client's session ID, and the server's session ID. The result and the master secret are used as input to PRF to obtain the keys:

PRF(master secret, "OpenVPN key expansion" || client random 2 || server random 2 || client SID || server SID)

After the key exchange, traffic can start flowing on the data channel. Packets on the data channel are encrypted and authenticated, using the keys just generated. When it's time to replace the keys, a new key exchange takes place. It's just like the original exchange, regardless of whether it's method 1 or 2. To help with the transition to new keys, OpenVPN maintains three sets of keys:

  1. The active keys

  2. The lame-duck keys, which are the retiring keys

  3. The detached lame-duck keys, which are used when the new key negotiation fails

These three sets of keys explain the key ID field in the packet header. The key ID indicates which of the three key sets was used for the packet.

OpenVPN Security

OpenVPN is by far the most secure of the lightweight VPNs that we have studied. It achieves this security by making use of existing proven protocols rather than inventing its own. The difficult authentication and key-exchange processes are accomplished by using the SSL protocol. The payload data is protected in a manner that is quite similar to that used by IPsec.

OpenVPN authenticates its sequence numbers and IVs, and the sequence numbers in the data channel are encrypted to help prevent leakage of information. On the other hand, the packet type and key state are revealed in the packet header. This allows an attacker to try to interfere with the control channel and perhaps prevent key negotiation.

The reliable control channel mitigates the fact that key-exchange packets can be identified. If an attacker attempts to prevent key renegotiation by blocking the relevant packets, the reliability layer will ensure that they are either delivered or that the VPN fails.

Finally, any flaws in the critical SSL protocol are likely to be publicly identified and fixed quickly. Because much of the work is done by OpenSSL, deployed systems can take advantage of updates by merely linking in the newest release of the library. There do not appear to be any published exploits of the OpenVPN protocols.


Section 8.6. Summary

8.6. Summary

In this chapter, we looked at four lightweight VPNs. We call them lightweight because they are less complicated and easier to configure than, say, IPsec. We examined the protocols and packet formats of each of the VPNs. Some of these VPNs have serious flaws and shouldn't be used in any situation that requires more than casual security.

Our study of these VPNs illustrates the problems that a VPN must solve and some of the ways of solving those problems. The use of ad hoc protocols almost always leads to security flaws. The more successful VPNs, especially OpenVPN, leverage existing, proven protocols.


Exercises

8.1 | Show the VTun encapsulation for Ethernet, serial, and pipe tunnels. Use either TCP or UDP for the transport.
8.2 | Suppose that VTun does not have the SSL library linked in, that the server sends the client a random challenge of (0xA2 0x49 0x8C 0x1F 0xE0 0x74 0x73 0x29 0xAE 0xDC 0x33 0x74 0x70 0xCA 0xBB 0x20), and that the client responds with (0xF2 0x20 0xE2 0x78 0xB0 0x15 0x10 0x42 0xCB 0xA8 0x63 0x1D 0x1E 0xAD 0xEB 0x41). What shared secret are they using? (We are ignoring the mapping into {a, . . . , p} that VTun uses to transmit the binary data as a string.)
8.3 | How could we improve the security of CIPE by changing the binary packet format and making corresponding changes to its processing?
8.4 | Provide an efficient implementation in your favorite programming language of the sliding-window mechanism that tinc uses for handling sequence numbers.
8.5 | Why are OpenVPN's OCC and PING messages unlikely to conflict with normal traffic on the data channel? Hint: What does "normal" traffic look like?
8.6 | Why doesn't OpenVPN use a single ACK number to acknowledge all previous messages, as TCP does?
8.7 | Explain the difference between OpenVPN's control-channel packet ID and message sequence number fields. Why does it require both?
8.8 | We have mentioned many times that encrypted data should also be authenticated to prevent various types of attacks. Why is it safe for the OpenVPN control channel to omit the HMAC field (that is, to not specify --tls-auth)?


Part 3: IPSec

    Chapter 9. IPsec

    Chapter 10. IPsec Architecture

    Chapter 11. AH

    Chapter 12. ESP

    Chapter 13. IKE

    Chapter 14. IPsec Futures

    Appendix A. Source Code

    Appendix B. Miscellaneous Software


Chapter 9. IPsec

    Section 9.1. Introduction

    Section 9.2. An Overview of IPsec

    Section 9.3. Road Map for Part 3

    Section 9.4. Summary

    Exercises


Section 9.1. Introduction

9.1. Introduction

In Part 2, we examined several VPN technologies and saw how they operate. All these VPNs encapsulate their packets at the transport layer or higher. In the next few chapters, we study a set of VPNs, collectively called IP Security (IPsec), that encapsulate their packets at the network layer. IPsec is the IETF standard VPN technology defined for the TCP/IP suite.

As we shall see, IPsec is large and complicatedin contrast to the lightweight VPNs we studied in Chapter 8; we could describe IPsec as a heavyweight VPN. This heavy-weightedness is a result of two things: flexibility in configuring an IPsec VPN and the fact that IPsec is usually tightly integrated with the TCP/IP stack and thus runs in the kernel.

The IPsec working group recently completed revisions to the IPsec protocols, and we can expect that these revisions will start to be deployed shortly. We discuss the revised protocols in Chapter 14.

The IPsec protocols borrow ideas from the U.S. government's network-layer security protocol, SP3 [NIST 1990], the ISO's Network Layer Security Protocol (NLSP) [ISO 1992], and the swIPe protocol [Ioannidis and Blaze 1993a, Ioannidis and Blaze 1993b].

The swIPe Internet Draft [Ioannidis and Blaze 1993b] has long since expired, of course, but copies are still available from Blaze's Web sitesee the bibliography.

The initial design of IPsec was done in 1992 by John Ioannidis, Phil Karn, and William Allen Simpson.


Section 9.2. An Overview of IPsec

9.2. An Overview of IPsec

IPsec consists of three major protocols:

AH | A protocol that provides data origin authentication, data integrity, and replay protection.
ESP | A protocol that provides the same services as AH but also offers data privacy through the use of encryption.
IKE | A protocol that provides the all-important key-management function. The alternative to IKE is manual keying, which IPsec also supports.

AH and ESP can operate in one of two modes. From an implementation point of view, these modes determine what the encapsulation will look like. The two modes are

Transport mode | A method of providing security to the upper-layer protocol of an IP datagram
Tunnel mode | A method of providing security to an entire IP datagram

At first blush, it's difficult to see why there are two modes instead of one or when we would prefer one to the other.

Similar questions apply to AH and ESP. If ESP can provide privacy and the same services as AH, why do we need AH? We address these questions in detail in the following chapters, of course, but for now, we merely note that the AH authentication function is slightly different from ESP's and that although tunnel mode is the more general type of encapsulation, it also requires more overhead in the datagram.

Much of the flexibility of IPsec comes from the ability to combine AH and ESP in various ways and to choose the type of encapsulation. It is possible, for example, to protect a datagram with both AH and ESP by first applying ESP to the datagram and then applying AH to the result. There are other possibilities as well, which we discuss in further detail in Chapter 10.


Section 9.3. Road Map for Part 3

9.3. Road Map for Part 3

Because IPsec is the most important VPN technology available for TCP/IP networks, we devote Part 3 to its study. As usual, we are not interested in the configuration or administration of any particular vendor's implementation but rather concern ourselves with how IPsec operates, what algorithms it uses, and what its packets look like on the wire. We want to be able to look at a network trace, such as the output from tcpdump, and determine whether a VPN is working correctly and if not, where it is failing. An understanding and appreciation of IPsec's behavior on the wire will also allow us to know which types of VPN configurations are possible and which are not.

We spend the rest of the text in a careful examination of IPsec. Chapter 10 examines the overall architecture of IPsec. We will see that although IPsec consists of just three protocols, they can be configured and combined in a flexible manner that allows finegrained control over a VPN. Unfortunately, this flexibility comes at the cost of increased complexity. As a general rule, complexity is the enemy of security, so the increase in complexity can lead to a decrease in security; see, for example, the introduction to [Ferguson and Schneier 1999].

The increase in complexity also means that IPsec is more difficult to configure and manage. This contributes to security weaknesses, of course, but it also means that IPsec VPNs require an expert to configure and maintain them. This last problem provided the impetus for the development of the lightweight VPNs that we studied in Chapter 8.

In Chapter 10, we see how the various components of IPsec work together to provide security at the network layer. We also introduce the notion of a security association (SA) and see how the SA is the locus of the shared state that constitutes an IPsec VPN. This state consists of such parameters as the keys used for encryption and authentication, the current sequence number, information about when new keys will have to be negotiated, and pointers to a description of the policy that is applied to packets traversing the VPN.

In Chapter 11, we study the Authentication Header (AH) protocol and see how we can use it to guarantee both that an IP datagram is from the peer that it purports to be from and that the datagram has not been tampered with during transport. During our investigation of AH, we examine some of the mechanisms, such as sequence numbering, that IPsec uses to provide security. We'll see that as the name suggests, AH provides an authentication, or integrity, function only; it cannot provide privacy services.

In Chapter 12, we study the Encapsulating Security Payload (ESP) protocol and see that it provides the privacy services that AH lacks. Indeed, ESP can provide both privacy and authentication services and that except for special cases, AH is not required at all. In some circumstances, ESP can provide limited protection from traffic analysis.

Traffic analysis uses the source, destination, length, and frequency of messages between peers to infer information about the messages' content. For example, a sudden increase in VPN traffic between a construction firm and one its suppliers may indicate that the firm is planning to use the supplier's product in a project that it is bidding on. This information might provide a vital advantage to a competitor that is also bidding on the project. See section 5 of [Voydock and Kent 1983] for a discussion of traffic analysis and its interplay with security mechanisms.

In Chapter 13, we see how IPsec handles the vital key-exchange problem. As we've seen repeatedly, key management is one of the most difficult problems to solve when setting up a secure communications channel. The Internet Key Exchange (IKE) protocol uses the Diffie-Hellman algorithm to exchange keying material with a peer and can also keep the keys fresh and provide perfect forward secrecy.

Finally, in Chapter 14 we examine changes to IPsec that are planned for deployment now or in the near future. We look at changes to IKE and see how NAT traversal can solve the problems between IPsec and NAT.


Section 9.4. Summary

9.4. Summary

This chapter serves as a brief introduction to IPsec and its protocols. It also lays out a road map for Part 3 of the text.

We noted that we will study the architecture of the AH, ESP, and IKE protocols and take a brief look at where IPsec will be going in the future. Although IPsec is often described as complex and difficult to understand, the underlying ideas are straightforward. If we understand how each of the protocols works, we will be able to troubleshoot VPNs by looking at network traces, and we'll understand how to combine the protocols into more complex VPNs.


Exercises

9.1 | What parts of an IP datagram should we protect with authentication? Can we protect the entire IP header? Does it make sense to protect any of the IP header?
9.2 | What parts of an IP datagram should we protect with encryption? Can we protect the entire IP header? Does it make sense to protect any of the IP header?
9.3 | Could we apply AH and ESP to an IP datagram by first applying AH and then ESP? What would be the advantages and disadvantages of doing so?
9.4 | Given the problems with manual keying that we have seen in previous chapters, why would IPsec require that it be supported by compliant implementations?


Chapter 10. IPsec Architecture

    Section 10.1. Introduction

    Section 10.2. Protocols

    Section 10.3. IPsec Modes

    Section 10.4. Security Associations

    Section 10.5. Combining Security Associations

    Section 10.6. Policies

    Section 10.7. IPsec Processing

    Section 10.8. Summary

    Exercises


Section 10.1. Introduction

10.1. Introduction

In this chapter, we look at the architecture that comprises and unifies the various IPsec protocols. We'll see that IPsec exactly meets our definition for a VPN: It's encryption and authentication applied to a tunnel in order to create the illusion of a private leased-line network. The overall architecture of IPsec is described in RFC 2401 [Kent and Atkinson 1998c], but separate RFCs describe its protocols and its encryption and authentication algorithms. Many of these RFCs are discussed in subsequent chapters.

RFC 2401 doesn't talk very much about VPNs, preferring instead to discuss such objects as "secured connections." When it does use the term VPN, the RFC applies it to the case of a secured IP-in-IP tunnel, called tunnel mode in IPsec. We take the position that all IPsec modes constitute a VPN (see Exercise 10.3) and use the term freely.

IPsec can be implemented in several ways in a host or security gateway. RFC 2401 describes three possible implementations:

  1. IPsec can be integrated into the TCP/IP stack itself. This implementation is probably the cleanest and most efficient but requires access to the kernel source and has the usual maintenance problems associated with kernel code.

  2. IPsec can be added just below the TCP/IP stack, usually as a pseudodevice driver. For example, one of the exercises in Chapter 11 asks us to implement a miniversion of AH, using our gtunnel driver. Such implementations are called bump-in-the-stack (BITS) implementations. Because such implementations can use tunnel driver techniques, such as gtunnel, or SYS V STREAM modules, they don't necessarily require access to the kernel source code.

  3. IPsec can be implemented as a stand-alone crypto device. Such devices are called bump-in-the-wire (BITW) implementations. Usually, such devices are added to a router or firewall, making the combination appear essentially like a security gateway.

Although RFC 2401 sometimes distinguishes among these types of implementations, the differences appear to matter only when considering the fine points of an actual implementation. For our purposes, we can imagine that IPsec is always integrated into the stack.


Section 10.2. Protocols

10.2. Protocols

As we saw in Chapter 9, we can think of IPsec as consisting of three protocols: AH, ESP, and IKE. IKE is the key-management protocol that negotiates VPN parameters between endpoints. We defer discussion of it until Chapter 13.

The other two protocols are the ones that provide security services to the VPN by encapsulating the IP datagrams that flow through it. We will see the exact encapsulations when we study AH in Chapter 11 and ESP in Chapter 12.

The AH protocol provides datagram-origin authentication, data integrity, and protection from replay attacks. The authentication and integrity services are provided by calculating a cryptographic MAC over a datagram's payload and parts of the datagram's IP header. Because the source and destination fields of the IP header are included in the MAC, we can be sure that those fields were not tampered with while the datagram was in transit. Because the payload is also included in the MAC, we can be sure that it wasn't tampered with either. Figure 10.1 shows an overview of AH encapsulation.

Figure 10.1. AH Encapsulation Overview

[View full size image]

Notice that the authentication covers only part of the IP header.

ESP also has an authentication function, which is almost identical to that provided by AH. The difference is that ESP authentication does not protect the IP header fields.

More precisely, ESP does not protect the outer IP header fields. As we'll see shortly, AH and ESP operate in two modes, one of which adds an additional IP header. In this mode, ESP protects the inner IP header but not the outer. AH, on the other hand, protects all the inner IP header and parts of the outer IP header.

It's a matter of some contention as to whether there's a compelling reason to have AH at all. Those who take the negative position (see [Ferguson and Schneier 1999], for example), point out that the outermost IP header is used only for routing and that possession of the authentication key proves that it's from the appropriate sender. Furthermore, an attacker who has compromised the authentication key can change the outer IP header in any way desired.

Those who take the affirmative position argue that some specialized applications require the additional securityRFC 2461 [Narten, Nordmark, and Simpson 1998], for example, specifies the use of AH for neighbor discovery messages when security is requiredand that in any event, some sites are using it. Those taking the affirmative position appear to be winning the argument, because the latest draft revision to RFC 2401 still includes AH.

Both AH and ESP also protect against replay attacks by including a sequence number in their protocol headers. The use of sequence numbers with an unreliable datagram delivery service, such as IP, is difficult because datagrams can be lost or delivered out of order. In Chapter 11, we see how IPsec solves this problem.

ESP also provides data confidentiality by encrypting parts of the datagram, including the payload. Figure 10.2 shows an overview of the ESP encapsulation.

Figure 10.2. ESP Encapsulation Overview

[View full size image]

Exactly what is encrypted besides the payload depends on the mode that ESP is using. We study this in Chapter 12.

Note that ESP can do everything that AH can, except authenticate the IP header fields, and provide confidentiality as well. For this reason, most real-world VPNs run ESP only and use it to provide both authentication and privacy. Of course, it's easy to imagine situations in which a combination of AH and ESP might make sense, and we examine some of those possibilities later in the chapter.


Section 10.3. IPsec Modes

10.3. IPsec Modes

As noted earlier, AH and ESP can operate in either transport mode or tunnel mode. In this section, we examine these modes and when we should use one or the other. We'll revisit these modes when we make our detailed examinations of AH (Chapter 11) and ESP (Chapter 12).

At a technical level, the two modes differ in how they encapsulate the data and thus in what data they protect. From an operational point of view, they differ in whether they are protecting communications between two hosts or protecting communications between two networks or between a host and a network.

Transport Mode

Transport mode is meant to be used between two fixed hosts, or to put it another way, when the VPN endpoints are the final destinations of the traffic in the VPN. In particular, transport mode cannot be used to connect two networks or a network and a host. Transport mode is illustrated in Figure 10.3.

Figure 10.3. A Transport-Mode VPN

The name transport mode comes from the fact that transport-mode VPNs protect the transport-layer data in the datagram.

This isn't quite accurate, because they also protect ICMP and similar protocol data. The point is that they protect data that comes after the IP header, which is most often data from a transport protocol. Looked at another way, a transport-mode VPN protects whatever protocol was originally specified in the protocol field (Figure 2.11) of the IP header.

From a practical standpoint, this means that the AH or ESP header is placed after the IP header in the datagram.

Figure 10.4 demonstrates this encapsulation. In the case of AH, of course, there is no IPsec trailer.

Figure 10.4. Transport-Mode Encapsulation

[View full size image]

The figure shows why transport mode can be used only where the VPN endpoints are the final destinations. On the one hand, the datagram must be delivered to the VPN endpoint so that it can be decrypted and/or authenticated. On the other hand, there is only one IP header, so its destination must be its final destination.

Transport-mode VPNs may seem limited, but notice that they provide end-to-end security. If our threat model doesn't trust other hosts on our or the remote network, a transport-mode VPN meets that constraint. The other type of IPsec VPN, tunnel mode, does not necessarily provide end-to-end security.

Tunnel Mode

The other mode that AH and ESP can operate in is called tunnel mode. It is more flexible than transport mode, but this flexibility comes at the expense of increased bandwidth requirements.

The typical use of tunnel mode is to connect either two networks or a host and a network: for example, a remote office network to a home office network, or a "road warrior" to the home network. Figure 10.5 shows an example of this. Note that access to the networks is through a security gateway.

Figure 10.5. Tunnel-Mode VPNs

[View full size image]

In the figure, the remote and home networks are connected through the tunnel-mode VPN by way of the security gateways, GW1 and GW2. These gateways handle the encryption, decryption, antireplay, and authentication functions. These security functions are completely transparent to the hosts on the two networksthey merely send datagrams to their peer on the other network just as they would if the gateways and VPN weren't there.

In the case of the remote host, the gateway function is built into the remote host itself. Everything is exactly like the two-networks situation, except that there is no network behind the remote host.

Just as transport mode is named for the fact that ESP or AH is applied to the transport data, tunnel mode is named for the fact that ESP or AH is applied to a tunnel. We can see this clearly in Figure 10.6, which illustrates tunnel-mode encapsulation. If we look closely at the figure, and compare it to Figure 10.4, we see that we can describe tunnel mode as transport mode applied to an IP-in-IP tunnel (Section 4.2).

Figure 10.6. Tunnel-Mode Encapsulation

[View full size image]

This fact explains both the name tunnel mode and how the security gateways function. The outer IP header's source and destination addresses are those of the security gateways (or the remote host and a security gateway). Thus, the VPN traffic is delivered to one of the endpoints, where the decryption and/or authentication is applied, and the outer IP header, IPsec header, and, if present, the IPsec trailer are removed. This leaves the inner IP datagram, whose IP header has the address of the final destination. The security gateway now forwards the inner IP datagram to its final destination.

The two IP headers are what allow the VPN endpoint to be different from the final destination and, ultimately, what distinguishes transport mode from tunnel mode. Notice that except for the IPsec protocol details, tunnel mode operates exactly like the tunnels that we encountered in Chapter 4.

There is no reason, of course, that we couldn't use tunnel mode instead of transport mode between two fixed hosts. In this case, the source and destination addresses of the inner and outer IP headers would be the same. The disadvantage of this is the extra bandwidth required by the additional IP header. Indeed, we could think of transport mode as an optimization of tunnel mode for the special case of two fixed hosts.

As pointed out in [Ferguson and Schneier 1999], it would be equally easy to compress the data in the inner IP header, allowing us to eliminate transport mode and the extra complexity it entails, at virtually no cost in extra bandwidth. Doing so would eliminate the need for AHbecause the inner IP header is completely protected in tunnel modeand would therefore simplify IPsec considerably.


Section 10.4. Security Associations

10.4. Security Associations

When speaking and thinking about tunnels or VPNs, we should always be aware of the seductive quality of the language we use. Even though we know better, it's easy to imagine that a tunnel or VPN is a physical thing: a "pipe" that we must build before we can send data through it. In actuality, of course, a tunnel or VPN, like a TCP "connection," is entirely notionalthe V in VPN, after all, stands for virtual. In truth, a tunnel's or VPN's data is carried in ordinary IP datagrams, just like any other data in a TCP/IP network. The tunnel or VPN really consists of shared state at the tunnel endpoints, and when we speak of building the tunnel or VPN, we really mean synchronizing the state between the endpoints.

In IPsec, this shared state is called a security association (SA) and is held in a data structure of the same name.

RFC 2401 takes a seemingly stronger view and uses the term security association to refer to the VPN itself. Note, though, that in light of our remarks in the previous paragraph, this is consistent with our use of the term.

The SA is the controlling entity in an IPsec VPN. We'll look at some of the state data constituting an SA in more detail shortly. For now, we merely note that it includes such things as the encryption algorithm and its keys, the authentication algorithm and its keys, the current sequence number, the antireplay window, the lifetime of the SAusually in time and bytesand an identifying number, the security parameter index (SPI): in other words, the data that the endpoints need to maintain the VPN.

Surprisingly, SAs are simplex; that is, they control traffic in only one direction, from host A to host B, say, but not from host B to host A. Thus, each VPN endpoint must have a pair of SAs: one for input and one for output.

We could also say, although no one does, that it's the VPN that's simplex and that in order for two hosts to communicate, they need two VPNs, one in each direction. See Exercise 10.2.

In practice, the simplex nature of SAs causes no confusion or problems, but [Ferguson and Schneier 1999] notes that it trades security-damaging complexity for no apparent benefit.

In addition to requiring an SA for each direction, VPNs must have a separate pair of SAs for each protocol. Thus, if a VPN uses both AH and ESP, each endpoint will have four SAs. SAs are distinguished by the triple <SPI, destination address, protocol>. The SPI is assigned to the SA by the destination host, so the triple uniquely identifies an SA on a given host. When more than one SA should be applied at the same time, the SAs are combined into an SA bundle. The SA-bundle concept eases the difficulty in locating the appropriate SAs to apply to a datagram.

One important question is how the SAs are created. IPsec provides for two procedures:

  1. The SAs can be created manuallyso-called manual keyingby the system administrator. Although simple, manual keying does not scale well to multiple VPNs, cannot automatically refresh keys when required by aging or sequence number wrapping, and, of course, suffers from the usual security problems of a long-lived key. Nevertheless, RFC 2401 dictates that a compliant implementation must support manual keying.

  2. The SAs can be negotiated as needed by the IPsec key-management protocol, IKE. Although more difficult to configure, IKE has the advantage that it can create an initial pair of SAs when a VPN is created and then maintain the VPN state by negotiating new SAs when keys expire, the sequence numbers wrap, or some other event forces a new SA. In addition, IKE can increase security by providing perfect forward secrecy.

We consider IKE in detail in Chapter 13.

An IPsec implementation holds the SAs in a security association database (SAD), where it can locate them during processing. Conceptually, there is a SAD for input and another for output, but whether there is one SAD or two is an implementation detail. For ease of discussion, we assume that a single SAD contains both inbound and outbound SAs.

The SAD is used in two ways. First, when it determines that an outbound datagram should have one or both of ESP or AH applied to it, IPsec looks up the SA or SA bundle in the SADor creates one if it doesn't already existto determine such parameters as the encryption and authentication algorithms, their keys, and the next sequence number. IPsec uses these parameters to form the encapsulated datagram. We look at this more when we discuss IPsec processing.

Second, when processing an incoming IPsec datagram, IPsec uses the SPI, destination address, and protocol from the datagram to locate the SA or SA bundle in the SAD. The SA or SA bundle provides the parameters needed to decrypt and/or authenticate the datagram.


Section 10.5. Combining Security Associations

10.5. Combining Security Associations

As mentioned above, it is sometimes useful to apply both AH and ESP to a VPN by combining multiple SAs into an SA bundle. In this section, we explore the ways in which we can combine AH and ESP and, more generally, how we can combine SAs to build complex VPNs.

The simplest situations combine AH and ESP in a single transport-mode VPN. This is called transport adjacency, and we illustrate the SAs involved and the encapsulation of the datagrams in Figure 10.7.

Figure 10.7. Transport Adjacency

[View full size image]

We use the same network diagram for each of the VPN configurations in this subsection. In some cases, such as Figure 10.7, parts of the network, such as the security gateways, play no part and may or may not be present.

Note that AH is applied after ESPthat is, AH is the "outer" protocol. This makes sense because we want to authenticate as much of the datagram as possible, including the ESP header.

The more general way of combining SAs to build VPNs is called iterated tunneling, which tunnels the result of a previous transport-mode VPN or a previous tunnel-mode VPN in another VPN. Let's examine some situations in which this makes sense.

Although RFC 2401 does not require that an implementation support it, we could imagine using iterated tunneling in the configuration of Figure 10.7. However, using iterated tunneling here provides no advantages over transport adjacency and requires one or two additional IP headers, depending on whether the outer SA tunnels a transport-mode SA or a tunnel-mode SA.

A more realistic example is shown in Figure 10.8: an end-to-end AH VPN in transport mode between H1 and H2. Between H1 and GW2, an ESP tunnel-mode VPN protects the privacy of H1's datagrams until they reach GW2, which is presumably on the destination network.

Figure 10.8. Iterating Tunneling with a Shared Endpoint

[View full size image]

The IP headers in the encapsulation are labeled with their source (S) and destination (D) to help tie the two parts of the figure together.

We could have used tunnel mode for AH, but this would have added another IP header, with no advantage over using transport mode. The inner protocol could be ESP instead of AH, but there appears to be little utility in doing so, because an end-to-end ESP VPN would make the one between H1 and GW2 superfluous.

The two VPNs in Figure 10.8 share a common endpoint at H1. Thus, H1 must know about both VPNs and have an SA bundle that describes them. Our next configuration also has two VPNs, but they share no endpoints, as shown in Figure 10.9.

Figure 10.9. Iterated Tunneling with No Shared Endpoints

[View full size image]

In this case, both VPNs use ESP. This could easily happen because H1 and H2 might not be aware of the existence of the VPN between the security gateways. Of course, the VPNs could use either AH or ESP, depending on the security requirements they are meant to satisfy. It's also perfectly legal for the VPN between the two hosts to use tunnel mode, although as in the previous example, there is no utility in doing so.

There are many other wayssome legal, some illegalof nesting VPNs. The best way of deciding whether a proposed nesting is legal is to lay out the encapsulations as we have done here. If the encapsulations make sense, the nesting will probably work.

In particular, if the nesting doesn't have two or more of the VPNs sharing a common endpoint and if the encapsulation makes sense, the nesting will be legal.


Section 10.6. Policies

10.6. Policies

In this section, we discuss how IPsec decides which datagrams to send through a VPN. We might think that a transport-mode VPN, such as that in Figure 10.3, would simply send all datagrams destined to the peer host through the VPN, and, indeed, this is possible. It's also possible, however, to have much finer granularity in the selection of datagrams that the VPN should carry. Similarly, we might think that a tunnel-mode VPN between two networks, such as that in Figure 10.5, would at most carry datagrams that had the peer network as a destination, but this is not correct. The peer network might contain a router or another security gateway that will route the datagram to a completely different network, so the VPN might carry datagrams whose final destinations are not on the peer network.

Thus, IPsec can select datagrams with a granularity that is both finer and coarser than we might expect. A rule stating which datagrams should be sent through an IPsec VPN is called a policy. A simple policy for a transport-mode VPN might simply require that every datagram addressed to the peer host go through the VPN. A more complex policy might say that only TCP traffic addressed to the peer should be sent through the VPN. An even more complex policy might specify that only UDP traffic with a specific destination port should travel through the VPN. Obviously, tunnel-mode VPNs provide for the possibility of even more types of policies.

The possibility of fine-grained selection means that we can have multiple VPNseven between two fixed hoststhat each carry a different type of traffic. So although Figure 10.3 shows a single VPN between the two hosts, and Figure 10.5 shows a single VPN between the two gateways, we can have multiple VPNs if the situation warrants. For example, if the DNS server for the remote network of Figure 10.5 is on the home network, we might want to establish an AH VPN to carry DNS traffic to prevent attacks based on forged DNS information. Although we want to authenticate that the DNS responses are coming from the correct DNS server and that they haven't been tampered with, it might not be worthwhile encrypting this traffic. At the same time, we might want to have another VPN for TCP and UDP traffic that does encrypt its datagrams.

A moment's thought makes clear that when applying a policy, IPsec must examine the IP header and, possibly, the transport header to see whether the datagram satisfies the conditions in the policy. The datagram fields that IPsec can use to make its decisions are called selectors.

We're considering only AH and ESP here. IKE has additional selectors, such as host and user identity, that it can use to decide whether to initiate a VPN.

RFC 2401 lists the following fields as possible selectors:

  • Destination address

  • Source address

  • Security label for networks that support them (see RFC 2401 for details)

  • Transport-layer protocol

  • Source port

  • Destination port

So far, we have talked about policies as a way of determining which datagrams should be sent through the VPN. The policy mechanism is more general in that associated with each policy is an action. That action can be to drop the datagram, to bypass IPsectransmit the datagram normallyor to apply one or both of the IPsec protocols. Thus, a policy is a rule that specifies the disposition of each matching datagram entering or leaving a VPN endpoint. RFC 2401 mandates that any datagram that does not have a matching policy must be dropped, but many implementations have a default policy that applies to datagrams that don't match any explicit policies. This is convenient when we have a VPN to another network, say, and want to send traffic to that network through the VPN but still send all other traffic out normally.

As with security associations, a node's IPsec policies are maintained in a database, called the security policy database (SPD). The SPD is consulted during output processing to determine the disposition of each datagram on the output queue. If the matching policy specifies that IPsec should be applied, there will be a pointer to the appropriate SA or SA bundle. If no SA or SA bundle exists, IPsec will invoke IKE to create one unless manual keying is being used, in which case the datagram will be dropped.

The SPD is also consulted for incoming datagrams. After the decryption and/or authentication of the datagram, the SPD is checked to ensure that the appropriate IPsec processing was performed.


Section 10.7. IPsec Processing

10.7. IPsec Processing

When we discuss AH and ESP, we will examine datagram processing by those protocols in detail. This section gives an overview of how IPsec processes packets and, in particular, how the SPD influences that process.

As noted earlier, every datagram, whether or not it is IPsec traffic, must have a matching policy or be dropped. Implementations that enable the system administrator to configure a default policy other than drop have, in effect, a wildcard policy that matches any datagram not matched by an explicit policy. This means that the default policy must be applied last. This same principle applies in general. The SPD is ordered, and the first policy that matches a datagram is the one used.

This is often convenient when we want to treat traffic to a specific host or set of hosts specially. Suppose that in Figure 10.5, for example, the remote network sends all traffic to the home network through the VPN. Suppose further that we don't want traffic for host Hs on the home network to flow through the VPN. In that case, we install a policy specifying that datagrams with a destination of Hs should bypass IPsec and then follow that with another policy saying that all traffic to the home network should flow through the VPN. Note that the order of policies is important.

Outbound Processing

Outbound processing consists of the following steps.

1.
Compare each outbound datagram's selector fields against the SPD to find the first matching policy. If this policy specifies that the datagram should be dropped, discard it and log the event. If the policy specifies that IPsec should be bypassed, transmit the datagram in the normal way. When the policy specifies that IPsec should be applied, it will point to a set of zero or more SAs or SA bundles in the SAD. If the set is empty, no SA exists for this policy, so IPsec will invoke IKE, assuming it is running, to negotiate the SAs with the appropriate peer. If IKE is not running, drop the datagram.

2.
Find the first SA or SA bundle in the set from the first step that applies to the datagram.

This step is necessary because a single policy rule can create multiple SAs. For example, it's possible to write a policy for the remote network in Figure 10.5 that says to send all traffic to the home network through the VPN but to create a separate SA for each source or destination host, effectively creating multiple VPNs. In this case, the single policy entry in the SPD will point to many SAs, and further checking is required to find the correct one.

3.
Use the SA or SA bundle to apply the appropriate IPsec services to the datagram. We will examine this step further when we discuss the AH and ESP protocols.

Inbound Processing

When a datagram arrives at a VPN endpoint, it is checked to see whether it contains an IPsec header, indicating that security processing must be applied. If it does, the following steps take place.

1. | Using the destination address, the SPI, and the type of header (AH or ESP), locate the SA that applies to the header. If this is tunnel mode, use the destination address of the outer header. If no SA is available, log and drop the datagram.
2. | If antireplay is enabled, check that the sequence number is valid. Using the SA found in the first step, perform the encryption and/or authentication specified by the SA. Verify that the resulting datagram's selectors match those specified in the SA. Repeat steps 1 and 2 until all the IPsec headers are processed.
3. | Locate the SPD entry that applies to the datagram by matching its selectors, just as in the outbound processing.
4. | Verify that the SAs found in steps 1 and 2 match the SAs required by the policy found in step 3 and that they were applied in the right order. Steps 3 and 4 are to verify that the datagram was processed correctly.
5. | Forward the decapsulated datagram to the next hop if this is not the final destination or to the appropriate transport protocol if it is.

ICMP Processing

ICMP error messages cause problems for IPsec in the same ways that we saw in Section 4.2. For example, a fragmentation required ICMP message for a tunnel-mode VPN may not have a sufficient number of bits of the original IP header to determine the sending host. Therefore, IPsec sometimes has to maintain soft state about the path MTU of the VPN, as described in Section 4.2 and RFC 2003 [Perkins 1996].

With IPsec, ICMP error messages present other problems as well. Recall that a VPN does not really exist in the Internet; except for its payload, a VPN datagram is just like any other datagram. This means that an intermediate router can trigger an ICMP error message about such a datagram and send it back to the originating VPN endpoint. Such a message will not be authenticated and would normally be dropped by IPsec. Doing this, however, can cause the endpoint to lose valuable information about the state of the network. On the other hand, such messages can be used in a denial-of-service attack, so dropping them may be prudent. RFC 2401 mandates that the system administrator be able to configure an endpoint to either accept or drop such packets as a matter of local policy.

Another problem with ICMP error messages is that they may not have the expected source address. After a VPN endpoint has applied the appropriate SA processing to a datagram, it must check that the resulting packet has selectors matching those specified in the SA. An ICMP error message may have a source address that does not match that specified in the SA, so IPsec must treat an ICMP error message as a special case and accept it even if the source address is incorrect.


Section 10.8. Summary

10.8. Summary

In this chapter, we looked at the architecture of IPsec, its constituent parts, and how they interoperate to provide security at the network layer. IPsec can be thought of as three protocols: AH and ESP, which provide security for individual datagrams, and IKE, which negotiates VPN parameters between the VPN's endpoints. We saw that AH and ESP can operate in either transport or tunnel mode, and that each has advantages and disadvantages. We noted that tunnel mode could be thought of as a special case of transport mode applied to an IP-in-IP tunnel, or that transport mode could be thought of as tunnel mode optimized for the special case in which the VPN endpoints are the final destinations.

We examined the concept of security association, and noted how it is central to, and perhaps identical to, an IPsec VPN. Security associations are held in a security association database, where they can be retrieved to process datagrams passing through a VPN. SAs are simplex, so full-duplex communication between VPN endpoints requires a pair of SAs at each endpoint. We noted that a complex VPN may require more than one SA to implement it and that the set of related SAs are gathered into an SA bundle for easy handling during processing.

Next, we looked at the notion of security policies and how they are implemented through the security policy database. The SPD is used to locate a policy to apply to a datagram; that policy, in turn, points to the appropriate SA or SA bundle that implements that policy.

Finally, we looked at how IPsec processes inbound and outbound datagrams. A datagram's selectors are used to find the matching policy to apply to outbound datagrams; we saw how that policy is mapped to an SA or SA bundle and how the SA is applied to the datagram. Similarly, we saw how IPsec uses an inbound datagram's destination address, SPI, and IPsec protocol to locate the SA that applies to it. After the processing specified by the SA takes place, the datagram is checked against the policy database to ensure that the proper SAs in the proper order were applied.


Exercises

10.1 | Make an argument that SAs do not have to be simplex. That is, rather than requiring a pair of SAs for each tunnel, one SA could handle both directions. What effect, if any, does this have on security? Hint: See [Ferguson and Schneier 1999].
10.2 | We noted that one could say that VPNs are simplex and that what we normally think of as a full-duplex VPN is actually two separate simplex VPNs, one in each direction. Defend this point of view. Defend the contrary view.
10.3 | Use the fact that AH and ESP are network-layer protocols to justify our use of the term VPN, even in the case of transport mode.
10.4 | What difficulties would there be in using a stream cipher, such as RC4, with ESP? Sketch out a way around these difficulties, and then read [Fluhrer, Mantin, and Shamir 2001].
10.5 | How is a transport-mode VPN different from an SSL or SSH connection between two hosts?
10.6 | Explain how an ESP tunnel-mode VPN can provide limited protection from traffic analysis. (See Chapter 9 for a definition of traffic analysis.)


Chapter 11. AH

    Section 11.1. Introduction

    Section 11.2. The AH Header

    Section 11.3. Sequence Numbers

    Section 11.4. AH Processing

    Section 11.5. Transport Mode

    Section 11.6. Tunnel Mode

    Section 11.7. AH with IPv6

    Section 11.8. Summary

    Exercises


Section 11.1. Introduction

11.1. Introduction

An unprotected IP datagram is subject to arbitrary manipulation by an attacker. The header is covered by the usual Internet checksum, but this provides protection only against corruption; an attacker can modify any of the header fields and be undetected by merely recalculating the checksum. The same principle applies to the data portion. Datagrams carrying TCP segments or UDP datagrams have their data protected by another Internet checksum, but again, the data is easily manipulated by an attacker, who needs only modify the data and recalculate the checksum.

Some situations require that hosts or networks be able to verify that IP datagrams are from whom they purport to be and that their payloads have not been tampered with in transit. As we shall see in Chapter 12, ESP can provide these services along with the confidentiality afforded by encryption. In some instances, however, confidentiality is not required, and in those cases, it makes sense to forgo the unneeded and expensive encryption step. The Authentication Header (AH) protocol provides endpoint authentication and data integrity without the overhead of encryption, thereby supplying exactly what's required in these situations.

In Chapter 12, we will see that ESP can also provide authentication and integrity functions without encryption. The IPsec working group consensus is that AH is still useful because its authentication function is subtly different from that of ESP. Not everyone agrees; see [Ferguson and Schneier 1999], for example.

The AH protocol is specified in RFC 2402 [Kent and Atkinson 1998a]. AH provides its protection by calculating a keyed MAC, called an integrity check value (ICV), over parts of the IP header and the entire payload data. The results of the ICV are placed in the AH header, and the header is added to the IP datagram. The exact placement of the AH header in the datagram depends on whether it is being used in transport or tunnel mode.

A moment's thought makes it clear that AH can't authenticate the entire IP header, because some of its fields are changed by intermediate routers. Figure 11.1 shows the fields of the IP header that AH does and does not authenticate.

Figure 11.1. IP Header Fields Authenticated by AH

[View full size image]

The shaded fields are mutable, are not covered by the authentication, and are zeroed before calculating the ICV. In addition, the destination address is specified as being mutable but predictable, meaning that it can be changed by intermediate routers but that the final value is known. The destination address is mutable but predictable when source routing is used. In this case, the predictable value is the final destination address, which is what the end host will see, so that value is filled in before the ICV is calculated.

Figure 11.1 doesn't show any IP options, but like the fields in the header itself, some options are mutable and must be zeroed before calculating the ICV. RFC 2402 has a complete list, but the common mutable IP options are the loose and strict source route, the timestamp, and the record route.

AH is an IP protocol and as such has its own IP protocol number: 51. As we'll see, the AH header always immediately follows an IP header, and the protocol field of that header will contain a 51, indicating that the datagram is carrying AH protocol data.


Section 11.2. The AH Header

11.2. The AH Header

Figure 11.2 shows the format of the AH header. As mentioned earlier, its exact placement in an IP datagram depends on whether we are using transport or tunnel mode. We will show the exact placement in the sections covering these modes.

Figure 11.2. The AH Header

[View full size image]

The next header field is the protocol number of the AH payload. For example, if AH is protecting a TCP segment, the next header field would contain a 6, the protocol number assigned to TCP. AH could be followed by an ESP (Chapter 12) packet or even another AH header, so we shouldn't think that only the TCP or UDP protocol numbers can occur in the next header field.

The payload length field is confusing for two reasons. First, despite its name, it is the length of the AH header, not the length of the payload that AH is protecting. Second, the length is expressed as 2 less than the number of 32-bit words in the header. For example, if the ICV is a 160-bit SHA-1 HMAC (five words), the length of the entire header would be eight 32-bits words, and the header length field would contain a 6.

The "minus 2" is an artifact of AH being an IPv6 protocol. In IPv6, extension header lengths are always expressed as the total length minus 64 bits, or in our case, two 32-bit words. The IPv6 extension header length convention is specified in RFC 2460 [Deering and Hinden 1998].

The security parameter index, along with the destination address and protocol (AH) identifies the SA to which this AH datagram applies. Values 1255 are reserved for future use and are not currently assigned. The value 0 is reserved for local use and is never transmitted to a peer. Thus, the legal values for the SPI are 256 through 232 - 1. The SPI is always assigned by the destination host, which is why the destination address is needed to uniquely identify the proper SA.

The sequence number field is a counter that increases by 1 for each AH datagram that a host sends for a particular SA. The initial value of the counter is 1. For reasons explained below, the sequence number is never allowed to wrap to 0. A sending host is required to check that the sequence number hasn't wrapped and to negotiate a new SA if it has.

The receiving host uses the sequence number to detect replayed datagrams. The checking on the receiving host's part is optional, and the receiver can inform the sender that it will not be checking sequence numbers, but the sender is always required to increment and send the sequence number. If its peer has informed it that it will not do sequence number checking, the sender can omit checking for sequence number wrapping. We will examine how the receiver checks the sequence numbers in the next section.

The authentication data field contains the result of the ICV calculation. The field is always a multiple of 32-bit words and must be padded in an arbitrary way if the length of the ICV in bytes is not divisible by 4. RFC 2402 allows the use of any MAC that the implementer wishes but requires that all implementations support at least HMAC-MD5-96 [Madson and Glenn 1998a] and HMAC-SHA1-96 [Madson and Glenn 1998b].

When calculating the IVC, the authentication data field is first zeroed and then replaced with the value of the IVC.


Section 11.3. Sequence Numbers

11.3. Sequence Numbers

We've seen many times that in order to prevent replay attacks, a VPN should use sequence numbers in its packets. These sequence numbers can be explicit, as they are with AH, or implicit, as they are with SSHv2.

Recall that with SSHv2, the current sequence number is an input to the HMAC calculation, but the sequence number itself is not sent.

AH and SSHv2 present two very different environments in which to implement sequence numbering. In SSHv2, the notion of sequence numbers is natural because SSH uses TCP to carry its messages, and TCP guarantees that it will either deliver all the packets in order or terminate the connection. Thus, SSHv2 need merely check that each message has the expected sequence number. An erroneous sequence number in SSHv2 is an indication of an error or an attack, so SSH will terminate the session.

Notice how much more difficult checking sequence numbers is for AH. Because AH operates at the (best-effort) network layer, there is no guarantee that a datagram, and therefore the AH header, won't be dropped, delivered out of order, or duplicated. Thus, it's not sufficient for AH to remember the next expected sequence number and to check that an incoming datagram's sequence number matches it. When a datagram arrives, its sequence number can be

  1. Greater than the largest sequence number received

  2. Less than the largest sequence number received but not a duplicate of a previous sequence number

  3. Equal to a previously received sequence number

Ideally, we would like to accept datagrams in cases 1 and 2, and drop datagrams in case 3. In principle, we could do this by remembering each sequence number that we receive, but such a plan is obviously impractical, considering that the AH sequence number space is 232 - 1 numbers long. Instead, IPsec uses the idea of the antireplay window, introduced in Chapter 8.

If we look at the three cases again, we see that the real issue is determining whether a packet is a duplicate. Remembering every sequence number received would allow AH to check for duplicates but is not practical. The antireplay-window idea refines the idea of remembering all the sequence numbers to remembering whether the last n sequence numbers were received.

Figure 11.3 shows an example of this with n = 4, that is, with a window width of four sequence numbers. The figure shows that the largest sequence number received was 35 and that AH has remembered the state of sequence numbers 32 through 35.

Figure 11.3. A Sequence Number Antireplay Window

Note that 35 is not necessarily the last sequence number receivedthat might have been 33merely the largest.

We see that sequence numbers 32 and 34 have not yet been received but that sequence numbers 33 and 35 have been.

Now let's consider how AH can use the antireplay window to decide whether to accept a datagram. AH uses three rules to make its decision. The first rule is to reject any datagrams with sequence numbers to the left of the window. Thus, even though sequence number 30 has not yet been received, it will be rejected if it is received, because it lies to the left of the window, and AH has forgotten its state.

The second rule covers sequence numbers that fall within the window. This rule is to accept a sequence number in the window if the sequence number is marked as not yet received (0 in Figure 11.3) and to reject it otherwise. Thus, sequence numbers 32 and 34 would be accepted, but sequence numbers 33 or 35 would be rejected. If a sequence number is accepted by the second rule, it is marked as received so that it won't be accepted a second time.

RFC 2402 specifies that the window should be updated only if the packet also passes the integrity check. This ensures that a forged datagram with a bad authentication value will not force the rejection of a subsequent legitimate datagram with the same sequence number.

Finally, the third rule covers the case in which a datagram is received with a sequence number to the right of the window. Obviously, any sequence number to the right of the window has not yet been seen, so it should be accepted. Figure 11.4 shows what happens if sequence number 37 is received when the antireplay window looks like Figure 11.3.

Figure 11.4. The Antireplay Window Slides Right

The antireplay window has slid two sequence numbers to the right so that the new sequence number (37) is at the right-hand edge. Sequence number 32 is now to the left of the window and will never be accepted, even if it's received later. Sequence number 34, on the other hand, is still in the window and will be accepted if it's received before the window moves again.

RFC 2402 specifies that the antireplay window must be at least 32 sequence numbers wide and recommends that it be 64. With the recommended width, AH can remember the state of the previous 64 sequence numbers, which will generally be enough to account for any packet that is actually going to arrive.

Notice that it is critically important that the sequence numbers not be allowed to wrap. If they do, an old datagram with sequence number n could be substituted for the current datagram with the same sequence number, thus effecting a replay attack. Therefore, when the sequence number is about to wrap to 0, a new set of SAs is negotiated. Because the new SAs will have a different SPI and, except in manual keying, a new authentication key, any previous datagram that is replayed will be rejected even if it has a legal sequence number.


Section 11.4. AH Processing

11.4. AH Processing

Before looking at the details of AH encapsulation, let's take a moment to understand how IPsec processes AH packets. The input and output processing is different, of course, so we will treat them separately.

AH Output Processing

When an AH SA is first established, usually through an IKE negotiation, the authentication algorithm and keys are recorded, and the sequence number counter is set to 0. When IPsec determines that an outbound packet should have AH applied, it locates the appropriate SA and performs the following steps.

1.
An AH header template is inserted between the IP and upper-layer headers.

2.
The sequence number is incremented and stored in the AH header. At this time, AH checks to ensure that the sequence number will not wrap. If it will, AH creates a new SA and initializes the sequence number to 0. In either case, the sequence number is incremented and stored in the AH header.

As indicated earlier, the peer can inform AH that it is not checking sequence numbers, in which case AH need not check whether the sequence number has cycled.

3.
The rest of the AH fields, with the exception of the ICV, are filled in.

4.
If required, arbitrary padding is added to the AH header to ensure that it is a multiple of 32 bits (64 bits for IPv6).

5.
The mutable fields in the IP header and the ICV field in the AH header are zeroed, and the ICV is calculated over the entire IP datagram. If a source routing option is present in the IP header, the destination address must be set to the final destination address before calculating the ICV.

6.
The mutable fields are filled in, and the ICV is stored in the AH header. If a source-routing option is present, the destination address field of the IP header is reset to the next intermediate destination.

7.
The IP datagram is placed on the output queue for transmission to its destination.

AH Input Processing

An authenticated IP datagram may have been fragmented on its way to its destination. If so, the fragments must be gathered and the datagram reassembled before AH can do any processing. Once an entire datagram is available, AH performs the following steps.

1. | Based on the SPI in the AH header and the destination address in the IP header, the applicable AH SA is located. If an SA that applies to the datagram cannot be located, the datagram is dropped.
2. | If sequence number checking is enabled, AH verifies the sequence number as described earlier. If the sequence number is too old or is a duplicate, the datagram is dropped.
3. | AH copies the IP and AH headers and zeroes the mutable fields of the IP header and the ICV of the AH header.
4. | The authentication algorithm and key specified in the SA are used to calculate an ICV for the entire packet, and the result is compared with the original value in the AH header. If the values do not match, the packet is dropped. If the values agree, the antireplay window is updated.
5. | The AH header is removed from the datagram, and the original IP header fields are restored. The datagram is placed on the input queue for normal IP processing.


Section 11.5. Transport Mode

11.5. Transport Mode

Transport mode is used to secure a connection between two hosts, as shown in Figure 11.5. That is, the endpoints are specific hosts rather than two networks or a host and a network.

Figure 11.5. An AH Transport Tunnel

In transport mode, the AH header is inserted into the IP datagram just after the IP header and options, as shown in Figure 11.6. Notice that we show only half of the IP header as being authenticated. This represents the fact that the mutable fields in the IP header are not covered by the authentication.

Figure 11.6. Transport-Mode AH Encapsulation of a TCP Segment

[View full size image]

We can see an example of this encapsulation by configuring transport-mode AH between laptop and bsd, as shown in Figure 11.7.

Figure 11.7. Testbed for AH

Once the tunnel is established, we ping bsd from laptop and capture the result with tcpdump:

1   18:00:02.334647 IP 192.168.123.5 > 192.168.123.1:
        AH(spi=0x0504cb4c,seq=0x1): icmp 64: echo request seq 512
1.1     4500 006c 00a8 0000 4033 0260 c0a8 7b05   E..l....@3.'..{.
1.2     c0a8 7b01 0104 0000 0504 cb4c 0000 0001   ..{........L....
1.3     3185 466e 8b64 587f b8e9 c757 0800 27b7   1.Fn.dX....W..'.
1.4     4b01 0200 f2dc 2c42 7425 0500 0809 0a0b   K.....,Bt%......
1.5     0c0d 0e0f 1011 1213 1415 1617 1819 1a1b   ................
1.6     1c1d 1e1f 2021 2223 2425 2627 2829 2a2b   .....!"#$%&'()*+
1.7     2c2d 2e2f 3031 3233 3435 3637             ,-./01234567

We show the AH header in boldface on lines 1.2 and 1.3. Comparing the dump with Figure 11.2, we see that the SPI and sequence number have the values shown in line 1. Notice that the length (4) is two less than the size of the header in 32-bit words (6), as expected. The part of the header on line 1.3 is the authentication dataHMAC-SHA1-96 in this case. Immediately following the AH header is the ICMP packet with a type of echo request (0x08).

If we look again at Figure 11.1, we see that the source address field of the IP datagram is part of the authenticated data. This means that AH cannot be used with NAT, because NAT will change the source IP address.

More precisely, AH cannot be used with an external NAT device as shown in the figure. Here, the AH tunnel runs from host A through the NAT device to host B.

If the host itself performs the NAT, and if it performs the NAT before it calculates the ICV, the NAT/AH combination will succeed.

This is the first of many problems that we will encounter between NAT and IPsec. For now, we merely note that AH will generally have difficulty with NAT because of the authenticated source IP address.


Section 11.6. Tunnel Mode

11.6. Tunnel Mode

Tunnel mode is used to connect two networks through a set of security gateways or a host and a network that is protected by a security gateway. Figure 11.8 shows a typical case for two networks; the case of a single host and a network is similar (Exercise 11.3). Notice that the AH tunnel runs between the gateways, not between hosts on the two protected networks.

Figure 11.8. A Tunnel-Mode AH Tunnel

[View full size image]

Because the security gateways must protect datagrams between arbitrary pairs of hosts from the two networks, the encapsulation is different. Rather than inserting an AH header between the IP header and upper-layer protocol header, we encapsulate the entire datagram by prepending IP and AH headers. We show this for a TCP segment in Figure 11.9. We show the authentication extending half way into the outer IP header. As before, this indicates that only the immutable fields of the IP header are authenticated. Also notice that the entire inner IP header is authenticated. This is possible because only the outer IP header will be examined and modified by intermediate routers; the inner IP header takes no part in the routing and is not changed.

Figure 11.9. AH Tunnel-Mode Encapsulation

[View full size image]

Let's see how this encapsulation would work in practice. Suppose that host H2 of Figure 11.8 wants to send a TCP segment to host H6 and have it protected by AH. Figure 11.10 shows the encapsulation at each point in the network. When the packet leaves H2, it has a source address of 10.0.1.2 and a destination address of 10.0.2.3, as expected.

Figure 11.10. Packet Flow in an AH Tunnel

The protocol field in the IP header is set to 6, indicating that the upper-layer protocol is TCP. When the packet leaves GW1, it has an IP header and an AH header prepended. The outer IP header has a source address of GW1 (96.1.1.1) and a destination address of GW2 (96.1.1.2). The protocol field of the outer IP header is set to 51, indicating that it is carrying an AH packet. The next header field of the AH header is set to 4, indicating that it is protecting an IP packet.

When the packet arrives at GW2, the outer IP and AH headers are stripped off, and the original datagram, as host H2 sent it, is delivered to H6. The inner IP datagram has not been changed in any way during the transit from H2 to H6.

If we build a tunnel-mode AH VPN between laptop and bsd, using the AH test bed of Figure 11.7, laptop can communicate with any host on the 172.30.0.0/24 network and have its datagrams protected by AH as they transit from laptop to bsd. Note, though, that the datagram is not protected as it moves from bsd to another host on the 172.30.0.0/24 network. If, after establishing the AH tunnel-mode VPN, we ping from laptop to linux and capture the traffic with tcpdump on bsd, we see the expected encapsulation:

1   17:59:43.012583 IP 192.168.123.5 > 192.168.123.1:
      AH(spi=0x0e9ec45c,seq=0x1): IP
      192.168.123.5 > 172.30.0.4: icmp 64:
      echo request seq 512 (ipip-proto-4)
1.1     4500 0080 0038 0000 4033 02bc c0a8 7b05    E....8..@3....{.
1.2     c0a8 7b01 0404 0000 0e9e c45c 0000 0001    ..{............
1.3     2040 b6f2 2283 92f6 39f8 8941 4500 0054    .@.."...9..AE..T
1.4     0037 0000 4001 92a2 c0a8 7b05 ac1e 0004    .7..@.....{.....
1.5     0800 cd58 3d01 0200 5ed1 3042 6e8f 0300    ...X=...^.0Bn...
1.6     0809 0a0b 0c0d 0e0f 1011 1213 1415 1617    ................
1.7     1819 1a1b 1c1d 1e1f 2021 2223 2425 2627    .........!"#$%&'
1.8     2829 2a2b 2c2d 2e2f 3031 3233 3435 3637    ()*+,-./01234567

The outer IP header is on lines 1.1 and 1.2. It has a source address of 192.168.123.5 (0xc0a87b05) and a destination address of 192.168.123.1 (0xc0a87b01). The AH header is on lines 1.2 and 1.3 in boldface. Its next header field is set to IP-in-IP (4). This indicates that an IP header follows the AH header.

As mentioned in Chapter 10, we can think of AH tunnel mode as AH transport mode applied to an IP-in-IP tunnel.

The part of the AH header on line 1.3 is the authentication data, which, like the transport example, is HMAC-SHA1-96. We see the inner IP header immediately following the AH header on lines 1.3 and 1.4. The source address is still 192.168.123.5 (0xc0a87b05), but the destination address is 172.30.0.4 (0xac1e0004), which is linux. The ICMP packet (the ping) starts on line 1.5 and has a type of echo request (0x08) as expected.

In AH tunnel mode, the situation with NAT is slightly different from what it was with transport mode. It is common for a security gateway to include router and NAT functions. In this case, the gateways can apply NAT before they calculate the ICV. When AH is used alonethat is, with no ESP encryptionit can see the transport-layer port numbers, so it can even apply PAT. On the other hand, NAT is often not necessary: In Figure 11.10, a datagram is carried between two networks with private IP address ranges without the use of NAT. In this respect, the AH tunnel is similar to the IP-in-IP tunnel that we saw in Chapter 4.


Section 11.7. AH with IPv6

11.7. AH with IPv6

The operation of AH with IPv6 is virtually the same as it is with IPv4. The only additional considerations are the mutable fields in the IPv6 header and the placement of the AH header in the IPv6 datagram. Figure 11.11 shows the IPv6 header with the mutable fields shaded. As in the IPv4 case, the mutable fields are zeroed before calculating the ICV. Similar to the IPv4 case and for the same reason, the destination address is mutable but predictable. The address of the final destination is used when calculating the ICV.

Figure 11.11. The IPv6 Header Mutable Fields

[View full size image]

Because IPv6 considers AH an end-to-end protocol, it comes after the hop-by-hop extension headers instead of immediately after the IP header. The destination extension headers can come before or after the AH header, but unless there is a compelling reason to do otherwise, it makes sense to protect those headers by placing them after the AH header. Thus, the AH encapsulation is a little more complicated with IPv6, because the AH header must be inserted among the other extension headers.

Figure 11.12 shows a typical encapsulation for AH transport mode with IPv6. The authentication extends to the middle of the IP header, as usual. The extension headers have been split into two parts: those that come before the AH header and those that come after. The next header field of the AH header will carry the number of the first inner extension header or of the upper-layer protocolTCP, in this case. Immutable fields in the outer extension headers are also included in the ICV calculation.

Figure 11.12. IPv6 AH Transport-Mode Encapsulation

[View full size image]

The encapsulation for tunnel mode is easier, just as it was for the IPv4 case. The entire IP datagram is encapsulated by prepending an outer IP header, possible additional extension headers, and an AH header, as shown in Figure 11.13.

Figure 11.13. IPv6 AH Tunnel Mode Encapsulation

[View full size image]


Section 11.8. Summary

11.8. Summary

In this chapter, we examined the AH protocol. AH can use transport mode to protect data between two hosts or tunnel mode to protect data between two networks or a host and a network. The protection afforded by AH is data-origin authentication and data integrity. Because it does not use encryption, AH does not provide privacy. An attacker can read AH-protected data but not tamper with it.

We looked at the input and output processing that IPsec must perform to implement AH. In particular, we studied how AH uses sequence numbers, even in the face of unreliable delivery, to prevent replay attacks.

Finally, we briefly looked at how the encapsulation of AH differs in IPv6. We saw that the major difference is that in IPv6, AH must deal with the extension headers.


Exercises

11.1 | We rejected as impractical the idea of checking sequence numbers by remembering each sequence number received. Describe an algorithm that checks sequence numbers by remembering sequence numbers that should have been received but weren't. Critique the practicality of this idea.
11.2 | Appendix C of RFC 2401 has a C code reference implementation for AH/ESP sequence number checking, but it uses a window that is 32 sequence numbers wide rather than the recommended 64. Modify the code in RFC 2401 to use a window of 64 sequence numbers.
11.3 | Draw a network diagram, similar to Figure 11.8, showing an AH tunnel between a host and a network protected by a security gateway.
11.4 | What is the trust model for Figure 11.8? That is, what assumptions is the network designer making about the security of the various parts of the network?
11.5 | With respect to Figure 11.8, how does the NAT situation change if NAT is applied by devices between GW1 and GW2 instead of by the security gateways themselves?
11.6 | Use gtunnel to build an AH-like authentication mechanism. For simplicity, use static keying and a single, fixed, authentication algorithm. Use either transport- or tunnel-mode encapsulation.


Chapter 12. ESP

    Section 12.1. Introduction

    Section 12.2. The ESP Header

    Section 12.3. ESP Processing

    Section 12.4. Transport Mode

    Section 12.5. Tunnel Mode

    Section 12.6. ESP with IPv6

    Section 12.7. Summary

    Exercises


Section 12.1. Introduction

12.1. Introduction

The Encapsulating Security Payload (ESP) protocol provides the same authentication, data integrity, and antireplay protection that AH provides but adds the IPsec confidentiality function. In tunnel mode, ESP also provides limited protection from traffic analysis. The ESP specification is RFC 2406 [Kent and Atkinson 1998b].

Except for the data authenticated and the placement of the authentication data in the packet, the ESP authentication function is identical to that in AH. Given this, we might wonder why ESP has its own authentication function or even why, given that the data is encrypted, we need authentication at all. It happens that unauthenticated ESP is vulnerable to certain remarkably simple cut-and-paste attackssee [Bellovin 1996] for details. Because of these attacks, ESP should always be authenticated, and therefore it makes sense to include the authentication function in ESP itself rather than require another set of SAs and another protocol header. As we shall see, ESP, unlike AH, does not authenticate the IP headerthe outer IP header in tunnel modeso it is sometimes useful to use AH in conjunction with ESP where the security model demands that the source address of an IP datagram be authenticated.

In [Ferguson and Schneier 1999], the Ferguson and Schneier argue that there is no reason why the IP header needs to be authenticated at all. The receiver knows that the packet was sent by someone who knows the authentication key, so authenticating the IP header, which is merely used to route the packet, does not appear to add any security. In any event, an attacker who knows the authentication key can just as easily forge the IP header and authenticate the forgery. Another point concerning using AH and ESP in tunnel mode is that RFC 2401 [Kent and Atkinson 1998c] does not require that implementations support nested AH and ESP in tunnel mode.

Both authentication and encryption are optional in ESP, but at least one must be used. The particular encryption and authentication algorithms used are specified in the SA. Either of the two functions may be disabled by specifying the NULL algorithm.


Section 12.2. The ESP Header

12.2. The ESP Header

The format of the ESP packet is shown in Figure 12.1.

Figure 12.1. The ESP Header and Trailer

[View full size image]

As with AH, the SPI, the destination address, and the IPsec protocol are used to uniquely identify the SA that applies to this packet. Also as with AH, the sequence number is used to provide the antireplay function. When the SA is established, the sequence number is initialized to 0. Before each packet is sent, the sequence number is incremented by 1 and placed in the ESP header. To ensure that no packet will be accepted more than once, the sequence number is not allowed to wrap to 0. Once the sequence number 232 - 1 is used, a new SA and, except in the case of manual keying, a new authentication key are established.

As we saw in Chapter 3, some encryption algorithms require an initialization vector, especially for block ciphers used in CBC mode. When an explicit IV is required, it is included in the payload data. In principle, we could send the IV in the first datagram and let the receiver cache the most recent encrypted block for use with the next block's CBC operation. In practice, the unreliable delivery of IP datagrams makes this impractical, and IPsec requires that an IV be sent with each IP datagram [Madson and Doraswamy 1998, Pereira and Adams 1998]. This makes sense because it makes the protocol simpler and allows the receiver to decrypt packets even if they arrive out of order or are lost, a common occurrence. The IV, if needed, and the payload data are placed in the IV and payload data field.

As we have seen, block ciphers require that plaintext be padded to a multiple of the block size. Such padding, if needed, is placed immediately after the payload data in the padding field. Even if a stream cipher or NULL encryption is used, we may require padding for alignment or data-hiding purposes. For example, the next header field must be right aligned on a 4-byte boundary, as shown in Figure 12.1, so that the authentication data will start on a 4-byte boundary. It is also possible to add a random number of padding bytes to hide the length of the payload data.

In any event, 0 to 255 bytes of padding are added to the payload data. Unless the encryption algorithm specifies otherwise, the first padding byte must be 0x01, the second 0x02, and so on. RFC 2406 says that the receiver should inspect the padding bytes to verify that they meet the prescribed values. This check serves to verify that the decryption was successful and provides a small amount of protection against cut-and-paste attacks when authentication is not used [Doraswamy and Harkins 1999].

The length of the padding is in the pad length field. It can take on any value between 0 and 255 inclusive. The pad length field is always present, even if there is no padding.

The next header field indicates what type of data is in the IV and payload data field. We shall see how the next header field is used and some of its common values shortly.

The authentication data field contains an integrity check value for the ESP packet. The ICV is calculated over the entire ESP packet except for the authentication data field itself. The ICV must start on a 4-byte boundary and must be a multiple of 32-bit words.

The two most common authentication methods are HMAC-MD5-96 [Madson and Glenn 1998a] and HMAC-SHA1-96 [Madson and Glenn 1998b]. Each method takes the first 96 bits from the HMAC-MD5 or HMAC-SHA-1 algorithm (described in Chapter 3) as the ICV. Although it is counterintuitive, restricting the output of the HMACs to the first 96 bits increases the security of the HMAC because it gives an attacker less information to work with. This is discussed in RFC 2104 ([Krawczyk, Bellare, and Canetti 1997]) and [Bellare, Canetti, and Krawczyk 1996].

For what follows, it is convenient to think of the ESP packet as consisting of four parts:

  1. The ESP header, which contains the SPI and sequence number fields

  2. The payload, which contains the IV and payload data fields

  3. The ESP trailer, which contains the padding, pad length, and next header fields

  4. The ESP authentication data, which contains the ICV.

We will refer to these fields in the rest of this chapter.


Section 12.3. ESP Processing

12.3. ESP Processing

Before looking at the details of the ESP transport and tunnel modes, we should understand how the TCP/IP stack processes ESP packets. The rules are slightly different for input and output, so we treat them separately.

ESP Output Processing

When it is ready to be placed on the output queue, an IP datagram is checked for possible IPsec processing. If ESP encapsulation is required, its exact form depends on whether the SA mandates transport or tunnel mode. We examine this in detail in the next two sections. Output processing involves the following steps.

1. | The SPD is searched for an SA that matches the appropriate selectorssource address, destination address, ports, protocol, etc.in the packet. If an SA doesn't already exist, a pair of SAs is negotiated (see Chapter 13).
2. | The sequence number from the SA is incremented and placed in the ESP header. If the peer has not disabled the antireplay function, the sequence number is checked to make sure that it hasn't wrapped to 0.
3. | Padding is added, if necessary, and the pad length and next header fields are filled in. If the encryption algorithm requires it, an IV is added to the payload data. The IV and data payload and the ESP trailer fields are encrypted, using the algorithm and key specified in the SA.
4. | The ICV is calculated over the ESP header, the IV and data payload, and the ESP trailer fields and placed in the authentication data field. The ICV is calculated, using the algorithm and key specified in the SA.
5. | If the resulting packet requires fragmentation, it is performed at this point. In transport mode, ESP is applied only to entire IP datagrams. In tunnel mode, ESP may be applied to an IP datagram fragment. For example, a VPN gateway may apply ESP to an IP datagram that was fragmented by the sending host.

The order in which the encryption and authentication functions are performed is important. Because authentication is performed last, the ICV is computed over the encrypted data. This means that the receiver can perform the relatively speedy authentication verification before performing the slower decryption process. This prevents an attacker from overloading the receiver by sending a flood of randomly encrypted packets.

See [Ferguson and Schneier 1999] for a contrarian view. The authors argue that "the meaning" and not "what was said" should be authenticated, and thus ESP should first authenticate and then encrypt. They point out that if concerns about DOS attacks require the current order, the encryption key should, at the very least, be part of the data authenticated. The principle here, which they call out as Lesson 3, is that not just the message but everything used to determine the meaning of the message should be authenticated.

It turns out that there is a "right" answer to this question. Krawczyk [Krawczyk 2001] shows that under fairly general assumptions about the encryption and authentication algorithms, encrypting and then authenticating is secure, but authenticating and then encrypting is not. In the context of IPsec, these results are less dispositive than we might hope, because he also shows that the order of encryption/authentication does not effect security when using a block cipher in CBC mode or a stream cipher.

ESP Input Processing

Because an IP datagram carrying an ESP packet may have been fragmented by intervening routers, the stack reassembles the IP datagram before performing the ESP processing. After any reassembly, the stack performs the following steps.

1. | The SA is retrieved by matching the destination address, protocol (ESP), and SPI of the packet. If no SA exists for the packet, it is dropped.
2. | If the antireplay service is enabled, the sequence number of the packet is checked to make sure that it is new and falls within the antireplay window.
3. | The packet is authenticated by computing the ICV over the ESP header, payload, and ESP trailer fields, using the algorithm and key specified in the SA. If the authentication fails, the packet is dropped; otherwise, the antireplay window is updated.
4. | The payload and ESP trailer fields are decrypted, using the algorithm and key in the SA. If padding was added, it should be checked to make sure it has the values appropriate for the decryption algorithm. The original IP datagram is reconstructed from the ESP packet. The details of this reconstruction depend on whether the SA specifies transport or tunnel mode.


Section 12.4. Transport Mode

12.4. Transport Mode

The IPsec protocols can operate in one of two modes: transport or tunnel. In this section, we investigate the operation of ESP in transport mode, which is used to secure the communication between two fixed hosts. That is, the ESP tunnel connects two specific hosts rather than several hosts on two networks. Transport mode is illustrated in Figure 12.2.

Figure 12.2. ESP in Transport Mode

In transport mode, ESP is used to secure the upper-layer protocols of the IP datagram. This usually means a TCP segment or a UDP datagram, but it could also be an ICMP packet or other legal IP protocol. Figure 12.3 shows the ESP encapsulation for a TCP segment. Notice that the ESP header is inserted after the IP header and its options but before the TCP header.

Figure 12.3. ESP Transport Encapsulation

[View full size image]

As we see in the figure, the payload, consisting of the TCP header and data, and the ESP trailer are encrypted. The ESP header is not encryptedotherwise, the receiver couldn't find the SPI and wouldn't know how to decrypt the packetbut it is authenticated. This means that an attacker can't, for example, substitute another SPI or sequence number.

Figure 12.3 also shows that the IP header is not protected. This means that an attacker can change any of the IP header fields without detection. Even though Figure 12.2 might make it appear that host A and host B are directly connected, the tunnel will, in general, traverse the Internet or other WAN, so at the very least, an attacker can see how much traffic is flowing between the two hosts and can forge IP headers (but not message content). On the other hand, the receiver of a transport-mode ESP packet can still be confident that it is from its peer, because only the receiver and its peer have the key to the authentication algorithm. This means that if an attacker attempts to forge an IP datagram, the ICV will be incorrect, and the authentication step will fail.

Let's look at transport-mode ESP in action. We set up an ESP transport mode tunnel between bsd (172.30.0.1) and linux (172.30.0.4). The policy for this tunnel, as seen on bsd, is

172.30.0.4[any] 172.30.0.1[any] any
    in ipsec
    esp/transport/172.30.0.4-172.30.0.1/require
    spid=9 seq=1 pid=9886
    refcnt=1
172.30.0.1[any] 172.30.0.4[any] any
    out ipsec
    esp/transport/172.30.0.1-172.30.0.4/require
    spid=10 seq=0 pid=9886
    refcnt=1

As usual, the policy comes in pairs. The second policy specifies that any IP datagram going to 172.30.0.4 from 172.30.0.1 should be encapsulated in an ESP transport-mode tunnel. The require keyword at the end of the third line of the policy indicates that the use of this SA is mandatory for any matching IP datagram. The first policy, which covers inbound traffic from 172.30.0.4, is similar. The exact meaning of the values in the printout are specific to the FreeBSD (KAME) implementation and needn't concern us.

Once the tunnel is established, we can display the SAs on bsd:

172.30.0.1 172.30.0.4
  esp mode=transport spi=2899419086(0xacd19fce) reqid=0(0x00000000)
  E: 3des-cbc 4679d9e8 76242719 575f9733 79f3f250 8eef4767 a40ca67f
  A: hmac-md5 c0646bc1 6421f527 0e873138 81ad53f1
  seq=0x00000042 replay=4 flags=0x00000000 state=mature
  created: Jun 1 13:12:37 2003current: Jun 1 13:29:00 2003
  diff: 983(s)hard: 28800(s)soft: 23040(s)
  last: Jun 1 13:26:54 2003hard: 0(s)soft: 0(s)
  current: 7984(bytes)hard: 0(bytes)soft: 0(bytes)
  allocated: 66hard: 0soft: 0
  sadb_seq=1 pid=9883 refcnt=2
172.30.0.4 172.30.0.1
  esp mode=transport spi=58938842(0x038355da) reqid=0(0x00000000)
  E: 3des-cbc e773a247 88d38f6d bc6058bb 86fa7212 2f4ecebd 1f5274cf
  A: hmac-md5 0cd852b6 47084ac3 33f3bb80 c331b54f
  seq=0x00000042 replay=4 flags=0x00000000 state=mature
  created: Jun 1 13:12:37 2003current: Jun 1 13:29:00 2003
  diff: 983(s)hard: 28800(s)soft: 23040(s)
  last: Jun 1 13:26:54 2003hard: 0(s)soft: 0(s)
  current: 5519(bytes)hard: 0(bytes)soft: 0(bytes)
  allocated: 66hard: 0soft: 0
  sadb_seq=0 pid=9883 refcnt=1

As with the display of the policy information, most of the information is implementation specific, but we do see that the tunnel is using Triple DES in CBC mode for encryption and HMAC-MD5 for authentication.

With the KAME IPsec implementation, the SPD and SAD are displayed via the setkey command. The meanings of some of the SPD and SAD fields displayed are documented in the setkey man page. The others, unfortunately, must be dug out of the source code.

To see what ESP transport-mode traffic looks like, we ping linux from bsd:

$ ping linux
PING linux.jcs.local (172.30.0.4): 56 data bytes
64 bytes from 172.30.0.4: icmp_seq=0 ttl=64 time=0.745 ms
64 bytes from 172.30.0.4: icmp_seq=1 ttl=64 time=0.672 ms
. . .

The first ping results in:

1   13:26:50.374973 172.30.0.1 > 172.30.0.4: ESP(spi=0xacd19fce,
    seq=0x3e)
1.1    4500 0078 a7b1 0000 4032 7a61 ac1e 0001    E..x....@2za....
1.2    ac1e 0004 acd1 9fce 0000 003e 2e10 4a32    ...........>..J2
1.3    e488 a012 f20b 1053 f265 43f2 257e 33e9    .......S.eC.%~3.
1.4    0355 b1de e40c e1a3 6164 021a 95ff 5595    .U......ad....U.
1.5    e14f 2e1e 93bc d607 4daf f014 2fc9 be94    .O......M.../...
1.6    9455 0e0e bfaf 59ea cec7 3111 5dd5 51a8    .U....Y...1.].Q.
1.7    1280 b4d3 84df 4a45 348e 5d7a 8183 439e    ......JE4.]z..C.
1.8    1689 a104 747e 3a4b                        ....t~:K

The first 20 bytes are the IP header (Figure 2.11), which is typeset in boldface. The tenth byte of the IP header is the protocol, a 50 (0x32), indicating that the IP datagram contains an ESP packet. Notice that the source and destination addresses are those of bsd, 172.30.0.1 (0xac1e0001), and linux, 172.30.0.4 (0xac1e0004), as expected.

The next 8 bytes are the ESP header:

1.2   ac1e 0004 acd1 9fce 0000 003e 2e10 4a32   ...........>..J2

The SPI is 0xacd119fce as in line 1. Similarly, the sequence number is 62 (0x3e).

The payload and ESP trailer (Figure 12.3) are encrypted, so we can't see them explicitly. We know that the payload is an ICMP echo request and therefore that the ESP trailer specifies that the next header is type 1 (ICMP). When we talk about tunnel mode in the next section, we will specify NULL encryption so that we can see the actual data and ESP trailer.

The last 12 bytes of the datagram are the authentication data, HMAC-MD5-96 in this case:

1.7   1280 b4d3 84df 4a45 348e 5d7a 8183 439e    ......JE4.]z..C.
1.8   1689 a104 747e 3a4b                        ....t~:K


Section 12.5. Tunnel Mode

12.5. Tunnel Mode

ESP tunnel mode is used to provide a VPN between two networks or between a host and a network. A typical configuration is shown in Figure 12.4, in which the two security gateways, GWA and GWB, connect networks A and B with a tunnel-mode ESP VPN. (Contrast this diagram with Figure 12.2.)

Figure 12.4. An ESP Tunnel-Mode VPN

[View full size image]

With this VPN in place, any host on network A can communicate securely with any host on network B. Before looking at how this works, let's examine the ESP tunnel-mode encapsulation. Figure 12.5 shows an IP datagram carrying a TCP segment before and after ESP encapsulation. As we see, the entire IP datagram is swallowed and encrypted by the ESP packet. This means that the ultimate recipient of the packet can be sure that the original IP header has not been tampered with during its transit of the WAN, because it is both encrypted and authenticated. Although the outer IP header is still vulnerable, the final datagram that gets delivered to the recipient is protected.

Figure 12.5. ESP Tunnel-Mode Encapsulation

[View full size image]

Another aspect of the ESP tunnel-mode encapsulation is that it provides some protection from traffic analysis. That is, an attacker who is capturing the packets as they transit the network is unable to determine the source or destination hosts. The only visible information is that some undetermined host on network A is communicating with some other undetermined host on network B.

The construction of the outer IP header follows simple and mostly obvious rules, which are specified in RFC 2401 [Kent and Atkinson 1998c]. Most of the fields in the outer IP header are constructed from scratch, using the expected values. These fields include the header length, total length, ID, fragment offset, checksum, TTL, protocol, and the source and destination addresses. The TOS field is copied from the inner header. The DF flag may or may not be copied, depending on implementation and configuration.

Looking again at Figure 12.4, we see that network A has an RFC 1918 private address, as does network B. Although this is not necessary, it is a common practice, and it will also illustrate how the nonroutable RFC 1918 addresses can be sent through the Internet or other WAN. We also see that GWA has a routable address of 1.1.1.1 on its WAN interface. Similarly, GWB has the routable address 2.2.2.2 on its WAN interface.

Assume that host A2 sends a TCP segment to host B3. Let's follow the IP datagram as it leaves host A2 until it reaches host B3. As shown in Figure 12.6, when the datagram leaves host A2, it is a "normal" IP datagram with a source address of 10.0.1.2 and a destination address of 10.0.2.3. The protocol field in the IP header is set to 6, indicating that the upper-layer protocol is TCP. Because host A2 either has its default route set to GWA or has a route to the 10.0.2.0/24 network with GWA as the next hop, the datagram is routed to GWA.

Figure 12.6. Packet Flow from Host A2 to Host B3

[View full size image]

When the datagram reaches GWA, the gateway checks its SPD and notices that it has a policy specifying that any datagram from the 10.0.1.0/24 network to the 10.0.2.0/24 network should be encapsulated with tunnel-mode ESP and sent to GWB at 2.2.2.2. After GWA encapsulates the IP datagram, the outer IP header has a source address of 1.1.1.1 (GWA) and a destination address of 2.2.2.2 (GWB). The protocol field of the outer IP header is 50, indicating that the upper-layer protocol is ESP. The next header field of the ESP packet is 4, indicating that the ESP packet is encapsulating an IP datagram. The inner IP header is unchanged.

When the encapsulated IP datagram arrives at GWB, the gateway sees that it contains an ESP packet and retrieves the authentication and encryption keys from the appropriate SA, performs the authentication checks, and decrypts the ESP payload. The outer IP header, the ESP header and trailer, and the ICV are stripped off, and the inner IP datagram is forwarded to its destination, which is 10.0.2.3 (host B3).

One more thing is worth noting in this example. Although neither of the gateways performs any NAT functions on the datagram as it passes through, we have connected two networks with private, nonroutable addresses. Unlike NAT, neither the inner IP header nor the TCP segment is modified.

Now let's look at an example of ESP tunnel mode on the wire. For this example, we set up an ESP tunnel-mode VPN between the 192.168.123.0/24 and 172.30.0.0/24 networks in our testbed. We will plug host laptop into the 192.168.123.0/24 network and use it to telnet into host solaris over the VPN. The relevant portions of our testbed are shown in Figure 12.7.

Figure 12.7. A Portion of the Network Testbed

Here is a copy of the IPsec policy on laptop:

172.30.0.0/24[any] 192.168.123.5[any] any
   in ipsec
   esp/tunnel/192.168.123.1-192.168.123.5/require
   spid=2 seq=1 pid=372
   refcnt=1
192.168.123.5[any] 172.30.0.0/24[any] any
   out ipsec
   esp/tunnel/192.168.123.5-192.168.123.1/require
   spid=1 seq=0 pid=372
   refcnt=1

The policy on bsd is the same except that the roles of the in and out directions are reversed. We have set the encryption algorithm to NULL so that we can see the contents of the ESP packets.

From laptop we telnet into solaris:

laptop:~
$ telnet solaris
Trying 172.30.0.3...
Connected to solaris.jcs.local.
Escape character is '^]'.

SunOS 5.8

login: guest
Password:
Sun Microsystems Inc.   SunOS 5.8         Generic February 2000
$

Here is the tcpdump output of the SYN segment from laptop to solaris:

1   18:50:51.262663 192.168.123.5 > 192.168.123.1: ESP(spi=0x09e95635,
    seq=0x34) [tos 0x10]
1.1     4510 0068 0788 0000 4032 fb74 c0a8 7b05    E..h....@2.t..{.
1.2     c0a8 7b01 09e9 5635 0000 0034 4510 003c    ..{...V5...4E..>
1.3     0787 4000 4006 4b56 c0a8 7b05 ac1e 0003    ..@.@.KV..{.....
1.4     040d 0017 1939 f0e5 0000 0000 a002 e000    .....9..........
1.5     c660 0000 0204 05b4 0103 0300 0101 080a    .'..............
1.6     0004 ae90 0000 0000 0102 0204 4d60 d80b    ............M'..
1.7     56a6 7e32 b9ac 51fc                        V.~2..Q.

The outer IP header is typeset in boldface. The tenth byte of the IP header (Figure 2.11) is the protocol number of the upper-layer protocol. As expected, it is set to ESP (50=0x32). The following two 32-bit words are the source and destination addresses192.168.123.5 (0xc0a87b05) and 192.168.123.1 (0xc0a87b01)as shown in line 1.

The next 8 bytes are the ESP header:

1.2   c0a8 7b01 09e9 5635 0000 0034 4510 003c   ..{...V5...4E..<

We see that the SPI is 0x09e95635 and that the sequence number is 0x34; both of these are shown on line 1 of the tcpdump output.

After the ESP header is the inner IP header. As before, the tenth byte of the header is the protocol, which this time has the value 6, indicating that the upper-level protocol contained in the IP datagram is TCP. The source address is again 192.168.123.5 (0xc0a87b05), the address of laptop. The destination address is 172.30.0.3 (0xac1e0003), the address of solaris:

1.2    c0a8 7b01 09e9 5635 0000 0034 4510 003c    ..{...V5...4E..<
1.3    0787 4000 4006 4b56 c0a8 7b05 ac1e 0003    ..@.@.KV..{.....

Next comes the TCP header (Figure 2.16):

1.4    040d 0017 1939 f0e5 0000 0000 a002 e000    .....9..........
1.5    c660 0000 0204 05b4 0103 0300 0101 080a    .'..............
1.6    0004 ae90 0000 0000 0102 0204 4d60 d80b    ............M'..

The fourteenth byte of the TCP header (0x02) contains the flags. This represents the SYN flag, as expected.

The next 4 bytes are the ESP trailer. The last 2 bytes of the trailer are the pad length and next header, as shown in Figure 12.1. We see that there are 2 bytes of padding (0x01 and 0x02) and that the next header is 4, reflecting that the ESP packet is encapsulating an IP datagram, as we saw earlier:

1.6    0004 ae90 0000 0000 0102 0204 4d60 d80b    ............M'..

Finally, the last 12 bytes are the 96 bits of the HMAC-SHA1-96 ICV:

1.6    0004 ae90 0000 0000 0102 0204 4d60 d80b    ............M'..
1.7    56a6 7e32 b9ac 51fc                       V.~2..Q.


Section 12.6. ESP with IPv6

12.6. ESP with IPv6

The operation of ESP with IPv6 is essentially identical to its operation with IPv4. The main difference involves the placement of extension headers in the ESP encapsulation. As we saw in Chapter 2, IPv6 options are carried in extension headers, each of which can carry hop-by-hop and routing options, or destination options.

When encapsulating with ESP, the hop-by-hop and routing options must be accessible to the intermediate routers and thus should not be encrypted or even, in most cases, authenticated. Destination options, on the other hand, need not be accessible to the routers, and we may want them encrypted or authenticated. This means that some of the extension headers will come before the ESP header and some after. In general, any header that intermediate routers need access to should be before the ESP header. Others may be either before or after, but placing them after ensures that they are protected, and it is good practice to do so.

Figure 12.8 is an IPv6 datagram encapsulated in a transport-mode tunnel. The extension headers of the original datagram are split into two parts: one placed before the ESP header and the other after. The next header field in the ESP trailer will carry the type of the extension header that immediately follows the ESP header. Note that this is different from the IPv4 case, in which the next header field would carry the type of the upper-layer protocol6 for TCP in the example of Figure 12.8.

Figure 12.8. IPv6 Transport-Mode Encapsulation

[View full size image]

We remarked before that in transport mode, the ESP protocol must not operate on fragmented IP datagrams. This poses a problem for bump-in-the-stack and bump-in-the-wire implementations (Chapter 10) because they may be presented with an already fragmented datagram. In the IPv6 case, this means that the ESP implementation must walk through the extension headers, looking for a fragmentation header. If one is found, the entire datagram must be reassembled, encapsulated in the ESP packet, and then refragmented.

In the case of tunnel mode, things are a little easier. The entire IP datagramextension headers and allare encapsulated in the ESP packet, so the implementation does not have to split them out. A set of new extension headers may need to be generated for the outer IP datagram, of course, but this is just the normal IPv6 processing. The result of IPv6 tunnel-mode encapsulation is shown in Figure 12.9.

Figure 12.9. IPv6 Tunnel-Mode Encapsulation

[View full size image]

As with IPv4, the construction of the outer IP header is straightforward. The version, length, hop limit, and source and destination addresses are constructed in the usual way. The flow ID can either be copied from the inner IP header or constructed anew. The class field may be constructed or copied. If we copy it and the inner IP header is an IPv6 header, we can merely copy the class. If the inner IP header is an IPv4 header, a legal case that we haven't explicitly covered, we map TOS to class. The next header field will be set to either ESP or the first outer extension header.


Section 12.7. Summary

12.7. Summary

In this chapter, we examined the ESP protocol and its role within IPsec. In addition to encryption, ESP provides authentication, antireplay protection, and, in some cases, limited protection from traffic analysis. We observed that like AH, ESP can operate in either transport or tunnel mode, and we looked at how the original datagram is encapsulated by ESP in the two modes.

We also watched ESP in action by taking tcpdump traces of ESP traffic. By using the NULL encryption algorithm, we were able to see the internal structure of an ESP tunnel-mode packet. On the other hand, when we looked at the traffic in a transport-mode tunnel, we did use encryption and were able to see what an attacker could see: the IP and ESP headers and the authentication data. Everything else was encrypted and effectively invisible. Even the size of the original data could be obscured by adding a random amount of padding.


Exercises

12.1

Some ISPs prohibit VPNs on home accounts by filtering ESP traffic. Given that the traffic is encrypted, how are the ISPs able to detect the ESP traffic?

12.2

Suppose that we are using a block cipher in CBC mode and that block i is corrupted in transmission. How many additional blocks will be affected?

This observation is the basis of the cut-and-paste attacks described in [Bellovin 1996]. Read that paper for further details and the reasons that authentication is essential.

12.3

What are the advantages and disadvantages of transport mode? Do you think that the advantages outweigh the disadvantages and extra complexity in ESP that transport mode requires? Read [Ferguson and Schneier 1999] for one view on this question.

12.4

Why must the destination machine be the one that chooses the SPI for an SA?

12.5

RFC 2401 makes a distinction between "hosts" and "security gateways." What is this distinction, and why might it be dismissed as artificial?

12.6

RFC 2406 notes that although the IV is often referred to as being part of the ciphertext, it is not usually encrypted. Is there any operational reason that the IV for a block cipher in CBC mode couldn't be encrypted? As [Schneier 1996] remarks, although many people worry about sending the IV in the clear, encrypting it protects only the first block, as the subsequent cipher blocks are available to an attacker. Can you think of any reason that encrypting the IV might increase the security of ESP? Hint: Read [Bellovin 1997] to see how predictable fields in the IP/TCP/UDP headers can provide data for a known text attack.


Chapter 13. IKE

    Section 13.1. Introduction

    Section 13.2. ISAKMP

    Section 13.3. IKE

    Section 13.4. An Example Negotiation

    Section 13.5. Summary

    Exercises


Section 13.1. Introduction

13.1. Introduction

The Internet Key Exchange (IKE) protocol is the third leg of IPsec. It handles the difficult problem of key management by negotiating security associations between a set of peers. The IKE protocol specification is RFC 2409 [Harkins and Carrel 1998].

The basic idea behind IKE is straightforward: The peers perform a Diffie-Hellman exchange to obtain a shared secret that they use to generate keying material for the encryption and authentication algorithms used to protect a VPN. As usual, expressing this simple idea in a robust and secure manner is far from trivial. IKE must take steps to protect itself against denial-of-service attacks, replay attacks, man-in-the-middle attacks, and other attempts to subvert the secure exchange of keys. In addition to exchanging keying material, IKE negotiates the encryption, authentication, and other cryptographic primitives that the VPN needs and agrees on the policy that the VPN will use, so the protocol must handle these aspects of SA creation as well.

IKE is often described as a hybrid protocol because it derives from three other key-exchange protocols. IKE uses the first of these, the Internet Security Association and Key Management Protocol (ISAKMP), as a base protocol in much the same way that FTP, say, uses TCP. ISAKMP is a framework that provides mechanisms and message formats for expressing additional protocols that establish security associations and perform key exchange. ISAKMP is independent of any particular key-exchange method; it is a general framework that can support many key-management protocols. ISAKMP is specified in RFC 2408 [Maughan, Schertler, Schneider, and Turner 1998].

The Oakley Key Determination protocol (OAKLEY) describes a series of modes that specify methods for using the Diffie-Hellman algorithm to securely exchange keying material while providing identity verification, authentication, and perfect forward secrecy. IKE's use of various modes comes from the OAKLEY protocol, as do the original four fixed groups defined in RFC 2409 that IKE uses for the Diffie-Hellman exchange. The latter are called OAKLEY groups. The OAKLEY protocol is defined in RFC 2412 [Orman 1998].

The SKEME protocol [Krawczyk 1996] is a versatile key-exchange protocol that provides perfect forward secrecy, key replacement, and the negotiation of cryptographic primitives. SKEME can also provide endpoint anonymity and repudiability. IKE borrows SKEME's method of using public key encryption for authentication and the idea of fast rekeying by exchanging nonces.

In this chapter, we see how IKE combines parts of the OAKLEY and SKEME protocols into the ISAKMP framework to provide a robust key-management service for IPsec. IKE is by far the most complex of the three IPsec protocols, so we take the time to make a careful examination of it. From an operational point of view, our time will be well spent, because almost all cases of an IPsec VPN "being down" involve a failure of IKE to negotiate the required SAs. Indeed, recalling our remarks from Chapter 10 concerning the equivalence between a VPN and its SAs, we could say that a VPN is "up" if and only if its SAs existthat is, if and only if IKE was able to negotiate the SAs.


Section 13.2. ISAKMP

13.2. ISAKMP

Although we needn't bother to examine the OAKLEY and SKEME protocols in detail, it is important to have a thorough understanding of ISAKMP because it provides the underlying mechanisms and message formats that IKE uses. ISAKMP is interesting in its own right, of course, because we can use it to implement many different key-exchange protocols. Nevertheless, we discuss ISAKMP only in the context of its use by IKE.

ISAKMP, like IKE, establishes SAs in two phases. In the first phase, the ISAKMP peers authenticate each other and establish a secure communication channel. In the second phase, ISAKMP negotiates VPN SAs. In IKE, for example, the AH and ESP SAs are negotiated in the second phase. The secure channel established in phase 1 can be used to negotiate several phase 2 SAs. We'll come back to the relationship between the two phases when we examine how they operate in IKE.

ISAKMP Cookies

One of IKE's goals is to guard against denial-of-service attacks. Because an attacker could merely flood an IKE node with random packets, it's not possible to provide absolute protection against DOS attacks, but we can protect against certain kinds of these attacks.

Recall that IKE uses a Diffie-Hellman exchange to derive a shared secret from which it generates other keying material. As we saw in Chapter 3, the Diffie-Hellman calculation involves exponentiation using big-number arithmetic and is therefore computationally expensive. One possible DOS attack is to flood an IKE node with IKE packets having random forged source addresses. The idea is to force the IKE node into making repeated, expensive, but useless, Diffie-Hellman calculations and thus make it unavailable for other work, including processing legitimate IKE messages.

ISAKMP prevents this attack by having the peers exchange cookies before making the expensive Diffie-Hellman calculations. When an ISAKMP node receives a message from its peer with the same cookie that it sent to that peer, it knows that the peer is at the specified source address; otherwise, it wouldn't have received the cookie that it is returning. After the first exchange, all further messages contain both cookies, which serve to identify that particular ISAKMP negotiation.

In order for this to work, the cookies must

  • Be bound to the two peers using them. That is, the cookie must be specific to those two peers and them only. This prevents an attacker from obtaining a cookie from another negotiation and then flooding an ISAKMP node with packets having this cookie and forged source addresses.

  • Not be forgeable by an attacker. That is, no one but the issuing ISAKMP node should be able to generate a cookie that the node will accept as legitimate.

  • Be limited to a single negotiation so that old cookies can't be replayed. This criterion is met by having the cookie depend on the time it was generated.

One obvious way of meeting these criteria is to take a cryptographic hash of a concatenation of the peers' IP addresses and ports, a date/timestamp, and a secret known only to the cookie creator. That is,

Equation 1

where CKY is the cookie, src is the source IP address and port, dst is the destination IP address and port, ts is a timestamp, and secret is a random secret known only to the issuer of the cookie.

ISAKMP doesn't specify how the cookie should be generated, only that it should meet the above criteria and be relatively inexpensive to calculate. Most implementations calculate the cookie by using some variation of the method in (1).

The ISAKMP Header

Every ISAKMP and IKE message begins with an ISAKMP header. This header identifies the particular negotiation to which the message belongs, indicates the type of the first payload that the message contains, specifies the length of the message, and contains flags and other information. Figure 13.1 shows the format of this header.

Figure 13.1. The ISAKMP Header

[View full size image]

The initiator and responder cookies were discussed in the previous subsection. They are each 8 bytes long. The node that sends the first message in a negotiation is called the initiator, and its cookie comes first. The responder is the other node.

The next payload field indicates the type of the first payload in the message. Each payload also has a next payload field in a manner reminiscent of IPv6 extension headers. Figure 13.2 shows the payload types that can be in these fields.

Figure 13.2. Payload Types

Value

Payload Type

0

None

1

Security Association

2

Proposal

3

Transform

4

Key Exchange

5

Identification

6

Certificate

7

Certificate Request

8

HASH

9

Signature

10

Nonce

11

Notification

12

Delete

13

Vendor ID

14127

Reserved

128255

Private Use

The major and minor version fields indicate the ISAKMP version that generated this message. Currently, the major version is 1, and the minor version is 0.

As we'll see, ISAKMP uses several types of exchanges. The exchange type field carries the type of exchange that this message is for. Figure 13.3 shows the ISAKMP exchange types. The exchanges marked with a bullet in the IKE column are used in the IKE protocol. Quick Mode and New Group Mode are specific to IKE.

Figure 13.3. Exchange Types0

Value

Exchange Type

IKE

0

None

1

Base

2

Identity Protection

•

3

Authentication Only

4

Aggressive

•

5

Informational

•

631

ISAKMP Reserved

32

Quick Mode

•

33

New Group Mode

•

34239

DOI Reserved

240255

Private Use

The flags field is a single-byte bit mask for flags. Currently, three flags are defined:

Encryption | (bit 0) When this bit is set, the payloads following the ISAKMP header are encrypted as specified in the ISAKMP SA. The SA is identified by the two cookies. This flag cannot be set until after the peers have exchanged keys.
Commit | (bit 1) This flag is used to synchronize the key exchangethat is, to ensure that encrypted data is not sent before the SA is fully established. Either side can set the bit; the other side must wait for a CONNECTED notify message before using the SA.
Auth. Only | (bit 2) Normally, all phase 2 ISAKMP traffic is protected by the ISAKMP SA. In particular, this traffic will usually be encrypted. When this bit is set, it indicates that the payload is a Notify message that is protected with authentication but not encryption. This is the only exception to the rule that phase 2 traffic is encrypted as specified in the ISAKMP SA.

The message ID field is used to identify the protocol state in phase 2 negotiations. This identifier is necessary because several phase 2 SAs can be negotiated simultaneously, and the message ID ties the message to a particular negotiation. The message ID is a random 4-byte number that is generated by the initiator of the phase 2 negotiation. The message ID is set to 0 during phase 1 negotiations.

The length field is the total length of the ISAKMP message in bytes. The length includes both the header and payloads.

ISAKMP Payloads

ISAKMP messages consist of possibly multiple payloads that carry the details of the SA being negotiated. Each payload consists of a generic header (Figure 13.4) and a data stream that is opaque to ISAKMP: Their formats and interpretations are defined by a domain of interpretation (DOI) document. In the case of IPsec, the DOI is RFC 2407 [Piper 1998].

Figure 13.4. The ISAKMP Generic Header

[View full size image]

The DOI is more general than indicated here. In addition to defining the payload formats and their interpretation, it also defines naming conventions, security policies, additional exchange types and notification messages, and the syntax for IPsec SA attributes and payloads. It defines, in short, what ISAKMP should negotiate.

As we see in Figure 13.4, the generic header is a 4-byte structure that specifies the length of the payload and the type of the next payload, if any.

Some payloads have associated attributes. For example, IKE has such attributes as encryption method, key length, group type, and so on. We discuss individual attributes as we encounter them.

There are two types of attributes: basic and variable length. Basic attributes are encoded as type/value pairs, whereas variable-length attributes are encoded as type-length-value triplets. We show the encoding of attributes in Figure 13.5. The AF flag indicates whether the attribute is basic (AF=1) or variable length (AF=0). For variable-length attributes, the length field is the length of the value. The variable-length attribute value field is present only when the AF flag is 0.

Figure 13.5. ISAKMP Attribute

[View full size image]

Basic attributes are never encoded as variable length, but variable-length attributes may be encoded as basic attributes if their values fit in 2 bytes.

As we see from Figure 13.2, there are 13 ISAKMP payloads. For the rest of this section, we discuss these payloads and their formats but restrict the discussion to their use in IKE.

The Security Association, Proposal, and Transform Payloads

The first task in both the phase 1 and phase 2 negotiations is for the peers to agree on the parameters for the SA protecting the exchange. The peers do this by exchanging SA payloads. Each SA payload contains one or more Proposal payloads, which, in turn, contain one or more Transform payloads. These payloads can be combined to express complex policies.

Let's begin with the formats of the three payload formats involved. The SA payload indicates the DOI and the situation under which the negotiation is taking place. Figure 13.6 shows the SA payload.

Figure 13.6. The SA Payload

[View full size image]

The next payload field contains the type of the next payload. This will not be a Proposal or Transform payload, because they are considered part of SA payload. The payload length field contains the length of the entire payload, including the SA payload itself, all the associated Proposal payloads, and all the associated transform payloads.

The DOI field indicates the domain of interpretation. For IPsec, this is 1. The value 0 indicates a generic phase 1 ISAKMP SA that can be used for any phase 2 protocol. The only other legal value is 2, which indicates the group domain of interpretation (GDOI). See RFC 3547 [Baugher, Weis, Hardjono, and Harney 2003] for more on the GDOI.

The situation field provides context for the negotiation. The length and form of this field are specified by the DOI. For IPsec, the situation field is a 32-bit bit mask, having the possible values

SIT_IDENTITY_ONLY | (0x01) This indicates that the security association will be linked to the identity information provided in an Identification payload.
SIT_SECRECY | (0x02) This indicates that labeled secrecy is required for this SA. See RFC 2407 [Piper 1998] for more on this and the SIT_INTEGRITY bit. No labeled domains are currently defined, so SIT_SECRECY should not be specified.
SIT_INTEGRITY | (0x04) This is similar to the SIT_SECRECY situation, indicating that the SA requires labeled integrity. No labeled domains are currently defined, so SIT_INTEGRITY should not be specified.

As we see from Figure 13.6, the SA payload structure does not specify any SA state variables but merely sets the context in which the SA negotiation will take place. The actual parameters are negotiated in the Proposal and Transform payloads, which are associated with the SA payload. Figure 13.7 shows the first of these: the Proposal payload.

Figure 13.7. The Proposal Payload

[View full size image]

The next payload field is the next-payload type within this SA payload. The only legal values are Proposal and None (see Figure 13.2). The length field contains the length of the entire proposal, including the Proposal payload itself, and all transforms associated with the payload.

The proposal number field is used to logically combine proposals. Proposals with the same proposal number are ANDed together; those with different proposal numbers are ORed together. In the case of ORed proposals, the initiator will list them in preferred order, and the responder will choose one of the proposals and include only that proposal in its response.

The protocol ID field specifies the protocol being proposed. Figure 13.8 shows the valid IPsec protocol IDs.

Figure 13.8. IPsec Protocol IDs

Value

Protocol ID

Protocol

0

RESERVED

1

PROTO_ISAKMP

Phase 1 protection

2

PROTO_IPSEC_AH

Authentication Header

3

PROTO_IPSEC_ESP

Encapsulating Security Payload

4

PROTO_IPCOMP

IP Compression

For phase 2 proposals, the SPI size field is the size of the SPI in bytes. For IPsec, this is always 4. Phase 1 SAs are identified by the initiator and responder cookies from the ISAKMP header and don't have a separate SPI field. The SPI size for phase 1 SAs can be any number between 0 and 16. Even if the SPI size is nonzero for a phase 1 SA, the SPI field will be ignored.

Each proposal has one or more associated transforms: encryption and authentication algorithms, for example. The number of transforms field specifies how many transforms are included with this proposal.

The SPI field is the sender's security parameter index for this proposal: for IPsec phase 2 proposals, a 4-byte integer. This field has no meaning for phase 1 proposals and will not usually be presentthat is, the SPI size field will be 0.

The Transform payload carries information about the cryptographic primitives that a proposal will use. For example, if a proposal is for ESP, we might have transforms specifying that AES in CBC mode and SHA-1 will be the encryption and authentication methods. The Transform payload is shown in Figure 13.9.

Figure 13.9. The Transform Payload

[View full size image]

The next payload field specifies the next payload for this proposal. The only legal values are Transform and None. This is similar to the situation with the Proposal payload's next payload field.

The payload length field is the size in bytes of the Transform payload. Unlike the case with the SA and Proposal payloads, this length does not include any other payloads.

The transform number field is similar to the proposal number field in the Proposal payload but can indicate only an OR combination. The initiator will list the transforms in preferred order. The responder will choose one of the transforms and include that transform only in its reply.

The transform ID field is a code indicating which transform is being proposed. Each of the protocols from Figure 13.8 has its own namespace for transform IDs, shown in Figure 13.10.

Figure 13.10. IPsec Transform IDs

Protocol

Value

Transform ID

DOI

ISAKMP

0

RESERVED

•

ISAKMP

1

KEY_IKE

•

AH

01

RESERVED

•

AH

2

AH_MD5

•

AH

3

AH_SHA

•

AH

4

AH_DES

•

AH

5

AH_SHA2_256

AH

6

AH_SHA2_384

AH

7

AH_SHA2_512

AH

8

AH_RIPEMD

AH

9

AH_AES-XCBC-MAC

ESP

0

RESERVED

•

ESP

1

ESP_DES_IV64

•

ESP

2

ESP_DES

•

ESP

3

ESP_3DES

•

ESP

4

ESP_RC5

•

ESP

5

ESP_IDEA

•

ESP

6

ESP_CAST

•

ESP

7

ESP_BLOWFISH

•

ESP

8

ESP_3IDEA

•

ESP

9

ESP_DES_IV32

•

ESP

10

ESP_RC4

•

ESP

11

ESP_NULL

•

ESP

12

ESP_AES_CBC

ESP

13

ESP_AES_CTR

ESP

14

ESP_AES_CCM_8

ESP

15

ESP_AES_CCM_12

ESP

16

ESP_AES_CCM_16

IPCOMP

0

RESERVED

•

IPCOMP

1

IPCOMP_OUI

•

IPCOMP

2

IPCOMP_DEFLATE

•

IPCOMP

3

IPCOMP_LZS

•

IPCOMP

4

IPCOMP_LZJH

Transforms marked with a bullet in the DOI column are defined in RFC 2407, the IPsec DOI. The other transforms were added after the publication of the DOI. Most of the transforms in Figure 13.10 are self-explanatory. Full explanations of each transform and a pointer to the relevant RFC are in RFC 2407. For those transforms not in the DOI RFC, the IETF Assigned Numbers Web site has an IPsec page listing all the values at <http://www.iana.org/assignments/isakmp-registry>.

The SA attributes field contains additional information about the transform. The attributes are encoded as in Figure 13.5. The phase 1 and phase 2 attribute types differ. The phase 1 types are shown in Figure 13.11; the phase 2 types, in Figure 13.12.

Figure 13.11. Phase 1 Attributes

Value

Attribute

Type

1

Encryption Algorithm

B

2

Hash Algorithm

B

3

Authentication Method

B

4

Group Description

B

5

Group Type

B

6

Group Prime/Irreducible Polynomial

V

7

Group Generator One

V

8

Group Generator Two

V

9

Group Curve A

V

10

Group Curve B

V

11

Life Type

B

12

Life Duration

V

13

PRF

B

14

Key Length

B

15

Field Size

B

16

Group Order

V

Figure 13.12. Phase 2 IPsec Attributes

Value

Attribute

Type

1

SA Life Type

B

2

SA Life Duration

V

3

Group Description

B

4

Encapsulation Mode

B

5

Authentication Algorithm

B

6

Key Length

B

7

Key Rounds

B

8

Compress Dictionary Size

B

9

Compress Private Algorithm

V

10

ECN Tunnel

B

11

Extended Sequence Number

B

A full explanation of these attributes and their legal values are discussed in RFC 2409 (phase 1) and RFC 2407 (phase 2). The phase 2 ECN Tunnel and Extended Sequence Number attributes are new since RFC 2407 and are discussed on the IPsec Assigned Numbers Web page.

We mentioned above that Proposal payloads can be logically combined by using the proposal numbers. Adjacent proposals with the same proposal number are ANDed together to form a single compound proposal. In IPsec, this is useful for combining AH and ESP in a single proposal. In this case, there would be two Proposal payloadsone for AH and one for ESPbut they would have the same proposal number, indicating that an AH AND ESP is being proposed.

Another common example is for the user to provide a list of alternatives from which the responder makes a single choice. For example, the initiator might propose ESP with a choice of 3DES, Blowfish, or AES for encryption. Each of these transforms will have a different transform number, indicating that the proposal is ESP with 3DES OR Blowfish OR AES.

An example will help make this mechanism clearer. Suppose that we wish to propose ESP with either AES_CBC or 3DES for encryption and AH with MD5. The ISAKMP message would have the structure shown in Figure 13.13. The arrows show the payloads to which each of the next payload fields refers.

Figure 13.13. Proposal Payload Structure

The Key Exchange Payload

The Key Exchange payload carries keying material used to generate a session key. This payload has the simple format shown in Figure 13.14.

Figure 13.14. The Key-Exchange Payload

[View full size image]

The next payload field contains the next payload type, as usual. The length field is the length of the entire Key Exchange payload, including the generic header.

The key-exchange data field contains the keying material used to generate a session key. This field's format is specified by the associated key-exchange algorithm.

The Identification Payload

One of the important goals of an ISAKMP negotiation is for the peers to identify themselves to each other and to authenticate that identification. As we'll see shortly, there are three methods of authenticating the identifications, but they all depend on the initial identification. That identification is carried in the Identification payload, shown in Figure 13.15. The figure shows the IPsec payload format as specified in the DOI (RFC 2407).

Figure 13.15. The IPsec Identification Payload

[View full size image]

The next payload and payload length fields are just as they were for the Key Exchange payload. As usual, the payload length includes the size of the header.

The ID type field indicates the type of data in the identification data field. Figure 13.16 lists the legal values for the ID type field.

Figure 13.16. ID Types

Value

ID Type

0

RESERVED

1

ID_IPV4_ADDR

2

ID_FQDN

3

ID_USER_FQDN

4

ID_IPV4_ADDR_SUBNET

5

ID_IPV6_ADDR

6

ID_IPV6_ADDR_SUBNET

7

ID_IPV4_ADDR_RANGE

8

ID_IPV6_ADDR_RANGE

9

ID_DER_ANSI_DN

10

ID_DER_ANSI_GN

11

ID_KEY_ID

12

ID_LIST

These types are mostly self-explanatory, but their meaning and formats are discussed fully in the IPsec DOI document.

The protocol ID field specifies an IP protocol type, such as UDP or TCP. A value of 0 means that the field should be ignored. The port field is the port associated with the protocol indicated in the protocol ID field. During phase 1 negotiations, these fields must either be 0 or have the values UPD/500.

Certificate Payloads

One of the methods of authenticating the identification of a peer is the exchange of certificates. Two types of payloads that address this: the Certificate Request payload (Figure 13.17) and the Certificate payload (Figure 13.18).

Figure 13.17. The Certificate Request Payload

[View full size image]

Figure 13.18. The Certificate Payload

[View full size image]

The next payload and payload length fields have the same meaning that we've seen in the last few payloads. As always, the length includes the header.

In the Certificate Request payload, the certificate authority field contains an encoding of a certificate authority acceptable to the requester. In the Certificate payload, the certificate data field contains an encoding of the certificate data. Both the cert. encoding and cert. type fields describe the type of certificate that is being requested or sent. Figure 13.19 shows the legal values for the certificate types.

Figure 13.19. Certificate Types

Value

Certificate Type

0

NONE

1

PKCS #7 wrapped X.509 certificate

2

PGP certificate

3

DNS signed key

4

X.509 certificate (signature)

5

X.509 certificate (key exchange)

6

Kerberos tokens

7

Certificate revocation list

8

Authority revocation list

9

SPKI certificate

10

X.509 certificate (attribute)

The Hash Payload

As we'll see shortly, ISAKMP and IKE exchange various hashes as a means of authenticating their messages. These hashes are carried in the Hash payload, shown in Figure 13.20.

Figure 13.20. The Hash Payload

[View full size image]

The fields in the generic header have the same meanings as they did for the payloads we've examined previously. The hash data field contains the results of the hash calculation. For example, if HMAC SHA-1 is used, this field will contain the 20 bytes of output from the SHA-1 calculation.

The Signature Payload

One of the ISAKMP identity authentication methods is for the peers to sign a hash of certain state known to both sides. The state is hashed and then encrypted, using the sending peer's private key. The receiving peer uses its peer's public key to decrypt the hash and verify it by calculating the same hash on its copy of the state. This is the usual digital signature procedure discussed in Chapter 3. Note that when a node verifies its peer's signature, it can be sure of the peer's identity because the peer will have the private key only if it is who it says it is.

The signature data is carried in a Signature payload, shown in Figure 13.21.

Figure 13.21. The Signature Payload

[View full size image]

The fields in the generic header have the same meaning that they do in the other payloads. The signature data field contains the signature itself.

The Nonce Payload

As noted earlier, a nonce is a (usually) random number meant to be used once and then discarded. ISAKMP and IKE make several uses of nonces and therefore need a way of exchanging them. Nonces are exchanged using the Nonce payload, shown in Figure 13.22.

Figure 13.22. The Nonce Payload

[View full size image]

The Nonce payload is virtually identical to several of the other payloads, such as the Key Exchange, Identification, Signature, and Hash payloads. The nonce is carried in the nonce data field.

The Notification Payload

The Notification payload plays a role within ISAKMP similar to that of ICMP within TCP/IP; it is used to carry information and error messages. Figure 13.23 shows the format of the Notification payload.

Figure 13.23. The Notification Payload

[View full size image]

The fields in the generic header have their usual meanings. The domain of interpretation field indicates which domain this notification is occurring under. For IPsec, this will be 1. The protocol ID field specifies the protocol identifier for this notification. For IPsec, these protocols are ISAKMP, ESP, and AH (Figure 13.8).

The SPI size field specifies the size of the following SPI field. For ISAKMP, the SA is identified by the initiator and responder cookies, so the SPI field is not used. In this case, the SPI size field may be any value from 0 to 16, but even if the size is nonzero, the SPI is ignored. For phase 2 IKE messages, the SPI size will be 4.

The notification message type field indicates the type of notification. Figure 13.24 shows the legal values for this field. The high numbers for the status messages are because of the partitioning of the message namespace. ISAKMP error messages are in the range 18,191, IPsec error messages in the range 8,19216,383, ISAKMP status messages in the range 16,38424,575, and IPsec status messages in the range 24,57632,767.

Figure 13.24. Notification Message Types

Value

Notification Type

Error/Status

1

INVALID-PAYLOAD-TYPE

E

2

DOI-NOT-SUPPORTED

E

3

SITUATION-NOT-SUPPORTED

E

4

INVALID-COOKIE

E

5

INVALID-MAJOR-VERSION

E

6

INVALID-MINOR-VERSION

E

7

INVALID-EXCHANGE-TYPE

E

8

INVALID-FLAGS

E

9

INVALID-MESSAGE-ID

E

10

INVALID-PROTOCOL-ID

E

11

INVALID-SPI

E

12

INVALID-TRANSFORM-ID

E

13

ATTRIBUTE-NOT-SUPPORTED

E

14

NO-PROPOSAL-CHOSEN

E

15

BAD-PROPOSAL-SYNTAX

E

16

PAYLOAD-MALFORMED

E

17

INVALID-KEY-INFORMATION

E

18

INVALID-ID-INFORMATION

E

19

INVALID-CERT-ENCODING

E

20

INVALID CERTIFICATE

E

21

CERT-TYPE-UNSUPPORTED

E

22

INVALID-CERT-AUTHORITY

E

23

INVALID-HASH-INFORMATION

E

24

AUTHENTICATION-FAILED

E

25

INVALID-SIGNATURE

E

26

ADDRESS-NOTIFICATION

E

27

NOTIFY-SA-LIFETIME

E

28

CERTIFICATE-UNAVAILABLE

E

29

UNSUPPORTED-EXCHANGE-TYPE

E

30

UNEQUAL-PAYLOAD-LENGTHS

E

16,384

CONNECTED

S

24,576

RESPONDER-LIFETIME

S

24,577

REPLAY-STATUS

S

24,578

INITIAL-CONTACT

S

The notification data field contains additional information about the error or status in the notify message type field. The IPsec DOI does not define any values for this field.

The Delete Payload

An IPsec endpoint can inform its peer that it is removing one or more SAs from its SAD by sending it a Delete payload. This message is informational only and does not request that the receiver remove the SA from its SAD. Of course, any further traffic on that SA will fail. Figure 13.25 shows the format of the Delete payload.

Figure 13.25. The Delete Payload

[View full size image]

The next payload and payload length fields have their usual meanings, as does the domain of interpretation field. The protocol ID field is the protocol that the SA or SAs are protecting. For ISAKMP SAs, the SPI size field will be 16the size of the two cookies; for IPsec SAs, it will be 4.

The number of SPIs field indicates how many SAs were deleted. Although several SAs can be specified in a single Delete payload, they must all be of the same protocol type because there is only one protocol ID field. The SPIs themselves are in the SPIs field. For ISAKMP SAs, this will be the 16 bytes of the initiator and responder cookies; for IPsec SAs, it will be the 4-byte integers identifying the SAs.

The Vendor ID Payload

The final payload is the Vendor ID payload, shown in Figure 13.26. Peers can, but need not, send this payload in order to determine that their peer is running the same ISAKMP implementation and that they can therefore exchange vendor-defined private-use payload types (Figure 13.2).

Figure 13.26. The Vendor ID Payload

[View full size image]

The next payload and payload length fields have their usual meanings. The vendor ID field is a hash of a vendor-chosen identification string. The choice of the string and hash function is left to the vendor. The vendor IDs are not registered with the IETF, so although RFC 2408 mandates that they must be unique, there does not appear to be a way of guaranteeing this.

ISAKMP Message Processing

By default, the ISAKMP messages are carried in UDP datagrams, using port 500 as the source and destination ports. Using UDP saves the connection setup and teardown of TCP but does not provide reliable delivery, so ISAKMP implements its own reliability layer.

Because message exchange in ISAKMP is very structuredas compared to TCP, say, where any data can be sent over a connectionthe reliability layer is quite simple. The messages are sent in lockstep: The initiator sends message X and waits for the responder to reply. When the responder does reply, the initiator sends the next message in the exchange type (Figure 13.3) currently under way. Because of this lockstep advancement of the state between the peers, no sequence numbers are necessary to ensure that packets aren't processed out of order. If the packet received does not have the correct payloads, it is rejected.

Thus, the reliability layer need be concerned only with ensuring that messages do not get lost. It does this in the usual way by implementing a retransmission timer. If the initiator does not receive the expected response to a message before the timer expires, the message is retransmitted unless the retry count is exceeded. RFC 2408 specifies that the retransmission timer must be adaptive. That is, it must adjust to changing conditions by using, for example, an exponential backoff like that of TCP.

ISAKMP defines five exchange types. Three of theseBase, Identity Protection, and Aggressiveare used for negotiating phase 1 SAs. The other twoAuthentication Only and Informationalcan be used in either phase 1 or 2. We won't discuss these exchanges heresee RFC 2408 for a complete descriptionbut IKE, as we'll see in the next section, makes use of the Identity Protection, Aggressive, and Informational exchanges.


Section 13.3. IKE

13.3. IKE

Our discussion of ISAKMP and its payloads was long and detailed but will make our examination of IKE much easier. Like ISAKMP, IKE has five exchange types, and three of them are instantiations of ISAKMP exchanges. The two new exchangesQuick Mode and New Groupare used only in phase 2 negotiations.

In the previous section, we did not examine the protocols used to implement the exchange types. We do that now, as we look at phase 1 and 2 negotiations in detail.

IKE Phase 1

Let's imagine two nodes that want to establish an IPsec tunnel between themselves. We can suppose that they have policies that allow such a tunnel and specify acceptable transforms, but at the start, they have no shared state. The purpose of phase 1 is to establish an encrypted, authenticated channel between the two nodes so that they can securely negotiate the appropriate IPsec SAs, such as ESP or AH. A further requirement of the phase 1 SA negotiation is that each node authenticate its identity to its peer. Thus, after the phase 1 SA is established, both peers will know that they are talking to the proper endpoint and will have a secure channel over which they can negotiate further SAs. Unlike phase 2 SAs, phase 1 SAs are bidirectional; that is, a single SA protects both inbound and outbound traffic.

IKE has two modes, or exchange types, that it can use to negotiate a phase 1 SA. The first of these, Main mode, is more flexible and can hide the identities of the endpoints, but it requires twice as many messages (six) as the other, Aggressive mode. Regardless of which mode is used, there are four ways of authenticating a peer:

  • A shared secret

  • A digital signature

  • Public key encryption

  • Revised public key encryption

Thus, there are eight ways of negotiating a phase 1 SA. We examine each one and remark on its benefits and disadvantages. It is easier to contrast Main mode and Aggressive mode if we consider them together for each of the authentication methods, but first, let's look at generic Main and Aggressive mode negotiations so that we can appreciate their differences without the distraction of a particular authentication method.

The IKE Main mode exchange is an instantiation of the ISAKMP Identity Protect exchange. Figure 13.27 shows a Main mode exchange. The exchange proceeds in three stages. First, the initiator sends a message that contains an ISAKMP header (HDR) and an SA payload (SA). As we saw in the previous section, the SA payload will contain a list of proposals and transforms from which the responder must choose. The responder replies with its own header and an SA payload that contains its chosen proposals and transforms.

Figure 13.27. A Generic Main Mode Negotiation

Recall that each side has also contributed a cookie in the ISAKMP header. The initiator sends its cookie, CKYi, and sets the responder's cookie field to 0. The responder contributes its own cookie, CKYr, and returns it and the initiator's cookie in its ISAKMP header. These two cookies are the identifier for this SA. When the responder gets the next message from the initiator, the message must have the same set of cookies, or the responder will abort the negotiation. Once the responder gets the second message, it knows that the IP address of the initiator is legitimate; otherwise, the initiator would not have received the responder's cookie. This is the protection against DOS attacks that we mentioned earlier.

In the next stage, the initiator sends a header, a Key Exchange payload (KE), and a nonce (NONCEi). The Key Exchange payload will contain the initiator's Diffie-Hellman private key, gxi (see Chapter 3), that the responder will use to calculate the Diffie-Hellman shared secret. The nonce serves two purposes: It will be used in the key-generation algorithms to ensure that each side contributes to the final keys, and, because it is used as part of the authentication procedure, it offers a proof of liveness. That is, the nonce enables a peer to detect whether an attacker is replaying an old exchange. We'll see this aspect in action when we examine the various authentication methods. The responder replies with its own header, Key Exchange payload, and nonce. At this point, both sides can calculate the Diffie-Hellman shared secret that is used to generate the keying material. As we'll see, the exact means of generating the keying material depends on the authentication method, but they use the Diffie-Hellman shared secret, the nonces, and the cookies as inputs.

In the third and final stage, the initiator sends a header, an Identification payload (IDi), and some authentication information (AUTH). We show the Identification and Authentication payloads in italics to indicate that they are encrypted, using the keys derived from the information in the first two stages. Notice how this protects the identification information. This may not make any sense until we realize that the two nodes can use proxies to negotiate their SAs for them. In this case, the identity of the proxies will be known from their IP addresses, but the identities of their clients will be hidden.

At the end of the Main mode exchange, the two nodes have agreed on encryption and data integrity algorithms for the phase 1 SA and have generated the keys for those algorithms. The two nodes can now use this SA to negotiate further IPsec SAs in the phase 2 negotiations.

Main mode requires the exchange of six messages. Aggressive mode, shown in Figure 13.28, requires only three. As the name suggests, the IKE Aggressive mode is an instantiation of the ISAKMP Aggressive mode.

Figure 13.28. A Generic Aggressive Mode Negotiation

In the first message, the initiator sends a header and SA, Key Exchange, Nonce, and Identification payloads. Notice that this combines the first two messages that the initiator sends in Main mode.

The responder replies with its own header and SA, Key Exchange, Nonce, and Identification payloads. It also sends some authentication information (AUTH). At this point, both sides can generate their keying material, and the responder has authenticated itself to the initiator.

In the final message, the initiator authenticates itself to the responder by sending it authentication information. The ISAKMP specification, RFC 2409, specifies that this last message should be encrypted, so we have shown it in italics. IKE makes the encryption of the last message optional, the idea being that the peers can delay the expensive key-generation operations until each side has authenticated itself to its peer.

Key Generation

IKE doesn't generate any encryption or authentication keys directly; that's up to the particular encryption and authentication algorithms that get negotiated. What IKE does do is provide keying material for those algorithms. That is, if the encryption algorithm requires 128 bits of data to generate a key, IKE will provide that data.

The keying material depends on the ISAKMP cookies, the nonces, and the Diffie-Hellman shared secret, but the exact method of calculation depends on the authentication method. The process begins with the calculation of the quantity SKEYID. This value is calculated in a distinct manner for each of the authentication methods and is why the keying material depends on the authentication method. We'll look at how SKEYID is calculated as we examine each authentication method.

Once we have SKEYID, we can calculate the other sources of keying material:

SKEYIDd = prf (SKEYID, gxixr||CKYi||CKYr||0)

SKEYIDa = prf (SKEYID, SKEYIDd||gxixr||CKYi||CKYr||1)

SKEYIDe = prf (SKEYID, SKEYIDa||gxixr||CKYi||CKYr||2)

where prf is a pseudorandom function that is negotiated in the SA payload. Currently, no pseudorandom functions are defined, so we use the default, which is HMAC, using whatever hash function was negotiated for authentication.

SKEYIDd is used to derive further keying material for non-ISAKMP SAs, such as those negotiated in phase 2. SKEYIDa is the keying material used to authenticate the ISAKMP negotiation. Similarly, SKEYIDe is the keying material used to encrypt the messages on the ISAKMP secure channel.

SKEYIDe will have however many bits the underlying hash function outputs. For example, if the prf function is HMAC-SHA-1, SKEYIDe will be 160 bits. If the negotiated encryption algorithm requires more bits, the key can be expanded by feeding it back into the prf function in the usual way:

K1 = prf (SKEYIDe, 0)

K2 = prf (SKEYIDe, K1)

. . .

Kn = prf (SKEYIDe, Kn-1)

K = K1||K2|| . . . ||Kn

Authentication with a Shared Secret

The simplest authentication method is for the two nodes to share a secret. This sounds vaguely like a password-based scheme, but although the secret is long lived, it is not a key and is never sent directly to a peer, even over an encrypted channel. Rather, it is used as an input into the key-generation operation and, through that, appears as part of an authentication hash. We'll look at the exact details momentarily.

Figure 13.29 shows a Main mode negotiation using a shared secret. Notice that the figure is identical to Figure 13.27 except that the authentication placeholders, AUTH, in the last two messages, are replaced with the two hashes HASHi and HASHr. For shared-secret authentication, we calculate SKEYID as

Figure 13.29. Main Mode with a Shared Secret

SKEYID = prf (shared_secret, body(NONCEi)||body(NONCEr))

where body(P) means the P payload minus the generic header. This is the only place that the shared secret is used.

The authentication is done by taking a hash over the Diffie-Hellman private keys, the cookies, and the bodies of the SA and Identification payloads:

HASHi = prf(SKEYID, gxi||gxr||CKYi||CKYr||body(SAi)||body(IDi))

HASHr = prf(SKEYID, gxr||gxi||CKYr||CKYi||body(SAi)||body(IDr))

Notice that these hashes authenticate all the relevant state and will not calculate the expected value unless the shared secret is correct. Thus, when each node verifies its peer's hash, it will know that the messages were not tampered with during transmission and that its peer possesses the shared secret and therefore is who it claims to be.

Figure 13.30 shows the message flow for Aggressive mode with shared-secret authentication. Notice that we have shown HASHi as encrypted, but as noted previously, IKE does not require this.

Figure 13.30. Aggressive Mode with a Shared Secret

Let's take a moment to consider the advantages and disadvantages of Aggressive mode over Main mode. The first advantage of Aggressive mode is clear: It requires only half the messages that Main mode does. Given the relative infrequency of ISAKMP negotiations between two peers, this may or may not be significant.

The second advantage is more subtle. Recalling Figure 13.29, we see that in Main mode, the responder must decide on what shared secret to apply to the negotiation, based on the initiator's IP address, because that is the only identification of the initiator it has when it calculates SKEYID. This means that it is not possible to negotiate the SA unless the responder can map the initiator's IP address to the correct shared secret. If we consider a mobile host with a variable IP address or the common case of a host that gets a dynamic IP address from its ISP's DHCP server, we see that Main mode with shared-secret authentication will not work in all situations.

With Aggressive mode, however, the peers receive the Identification payload at the same time they receive the Key Exchange payload and are therefore able to deal with hosts whose IP addresses they don't know beforehand. This means that the responder can use the information in the Identification payload to determine the shared secret, rather than depending on the IP address. With the increasing use of mobile computers, this is a significant advantage.

On the other hand, Aggressive mode suffers from a lack of flexibility. Because the Key Exchange payload is sent in the same message as the SA payload, the peers cannot negotiate which Diffie-Hellman group to use, as they can with Main mode. Also note that Aggressive mode does not hide the identification information as Main mode does. This may or may not be a problem, depending on the threat model.

Authentication with Signatures

Authentication with signatures is similar to that with shared secrets, but instead of including a shared secret in the SKEYID calculation, the peers digitally sign the hashes HASHi and HASHr.

Figure 13.31 shows the message flow for Main mode with signatures; Figure 13.32, for Aggressive mode. Instead of including HASHi and HASHr directly, as with shared-secret authentication, the hashes are signed and their signatures sent instead. That is, SIGi and SIGr are the signatures of HASHi and HASHr respectively.

Figure 13.31. Main Mode with Signature Authentication

Figure 13.32. Aggressive Mode with Signature Authentication

RFC 2409 specifies that the function used to generate the signature should be the prf function, unless the signature method negotiated mandates a particular hash. For example, DSS mandates the use of SHA-1 (see Chapter 3).

When RSA signatures are used, the signatures are encoded as a private key encryption (not signature) in PKCS #1 format.

After a peer has the Key Exchange payload, it calculates SKEYID as

SKEYID = prf (body(NONCEi)||body(NONCEr), gxixr )

SKEYIDd, SKEYIDa, SKEYIDe, and the two hashes HASHi and HASHr are calculated just as they were for the shared-secret authentication method.

Notice from the figures that each side can optionally include a certificate. This is a convenient way of handling authentication with signatures. For example, an organization might distribute certificates signed by the organization to each of its "road warriors." When the mobile host negotiates its phase 1 SA, it sends the certificate that contains its public key to the responder, which might be a security gateway on the organization's network. The responder can use the public key to verify the signature; because the certificate is signed, the responder knows that the public key is legitimate.

Authentication with Public Key Encryption

In authentication with public key encryption, each node encrypts the Nonce and Identification payloads with the public key of its peer. The peers prove their authenticity with the exchange of the HASHi and HASHr payloads. Because these hashes include the encrypted data in their calculations, sending the correct hash implies that the sender was able to decrypt the message and thus possesses the private key.

Looking at the Main mode (Figure 13.33) and Aggressive mode (Figure 13.34) exchanges helps make this clearer. In the message flow diagrams, Px(Y) indicates the encryption of the body of Y with the public key of x.

Figure 13.33. Main Mode with Public Key Encryption Authentication

Figure 13.34. Aggressive Mode with Public Key Encryption Authentication

The generic header is still included in the payload but is in the clear. Thus, Px(Y) consists of the generic header of Y in the clear, followed by the body of Y encrypted by the public key of x.

It may be that a responder has several public keys available for use. In that case, the initiator can send a hash of the certificate containing the key that it used. We show this as the optional HASH1 in the two figures. The hash is calculated with the negotiated hash algorithm.

This really makes sense only for Main mode where the SA negotiation is complete. The IKE specification, RFC 2409, does not give any guidance as to which hash function should be used in Aggressive mode.

Using public key encryption for authentication has several advantages. In the first place, there is extra security, because an attacker must break both the Diffie-Hellman exchange and the RSA encryption to obtain the state needed to generate the session keys. Second, this method offers both sides repudiation. Because either side could generate the entire exchange, there is no proof that a conversation between the two peers actually took place. Finally, note that this authentication method hides the Identification payloads even in Aggressive mode.

Authentication with Revised Public Key Authentication

Although public key authentication offers advantages over the other methods we've examined, it requires each node to perform four expensive public key calculations: two encryptions and two decryptions. Recall from Chapter 3 that each of these calculations can take up to two orders of magnitude more time than even a slow symmetric encryption. This won't matter much if we're setting up a single VPN between two hosts, but it can become a significant overhead on a busy security gateway that is handling hundreds of VPNs between multiple endpoints.

To alleviate this problem, IKE offers authentication with revised public key encryption. This mode offers all the advantage of authentication with public key encryption, but with half the public key calculations. The basic idea is that only the Nonce payload is encrypted with the public key; the Key Exchange, Identification, and optional Certificate payloads are encrypted with a symmetric encryption algorithm using a key derived from the nonce. The optional certificate provides the responder with the initiator's public key.

Figure 13.35 (Main mode) and Figure 13.36 (Aggressive mode) show the message flows for this method.

Figure 13.35. Main Mode with Authentication, Using Revised Public Key Encryption

[View full size image]

Figure 13.36. Aggressive Mode with Authentication, Using Revised Public Key Encryption

[View full size image]

The notation EKx (Y) indicates symmetric encryption of the body of Y, using a key derived from NONCEx.

As with Px(Y), the generic header is still included in EKx (Y) but is in the clear.

The symmetric encryption algorithm is the one negotiated in the SA payload.

The symmetric keys Ki and Kr are derived from keying material Ni and Nr, respectively, according to the encryption algorithm's specification. The keying material is derived from the nonces NONCEi and NONCEr as follows:

Ni = prf(body(NONCEi), CKYi)

Nr = prf(body(NONCEi), CKYr)

If this doesn't produce enough keying material for the encryption algorithm, the keying material is expanded exactly as it is for SKEYIDe.

New Group Exchange

As we've seen, ISAKMP and IKE have several predefined groups that the peers can use for making their Diffie-Hellman calculations. Additional groups may be negotiated in Main mode by sending the group attributesprime and generator for Diffie-Hellman over Zp, for examplein the negotiated Transform payloads. In addition, the peers can negotiate a new Diffie-Hellman group after phase 1 has concluded, by using the new group exchange.

Although the New Group exchange can take place only after the conclusion of phase 1, it is not a phase 2 negotiation. We should think of it as taking place outside of either phase 1 or phase 2 but only after phase 1.

As with groups negotiated with Main mode, the new group can be specified either with its predefined group number or by sending its attributes. The receiving peer should verify that the group is acceptable and respond with a Notify message if it's not.

Figure 13.37 shows the message flow for a New Group exchange.

Figure 13.37. The New Group Exchange

The two hashes are calculated as:

HASH1 = prf(SKEYIDa, MsgID||SA)

HASH2 = prf(SKEYIDa, MsgID||SA)

The two hashes guarantee livenessthat is, protect against replayby including the message ID field from the ISAKMP header. Recall that every exchange that takes place over a phase 1 SA has a unique message number.

Although Figure 13.37 shows an initiator and a responder as usual, these roles may not be the same as they were during phase 1. That is, if host A initiates a phase 1 SA negotiation to host B, it is perfectly legal for host B to be the initiator of the New Group exchange.

The phase 1 cookies, CKYi and CKYr, retain their association with the original hosts and remain in the same order in the ISAKMP header. That's because those cookies are used to identify the phase 1 SA.

This same principle applies to phase 2 exchanges. Either peer may play the role of initiator.

Phase 2Quick Mode

Once a phase 1 SA is established, the peers can use it to negotiate phase 2 IPsec SAs. They do this with a phase 2 Quick mode exchange. The name comes from that fact that if perfect forward secrecy is not required, the two SAs can be negotiated very quickly with three messages and without requiring any expensive Diffie-Hellman calculations. If perfect forward secrecy is required, the exchange still requires only three messages, but the peers include optional Key Exchange payloads in the messages. Similarly, the identities of the peers are assumed to be determined by their IP addresses, unless they include optional Identification payloads. Figure 13.38 shows the message flow of a typical Quick mode exchange. We also show the optional Key Exchange and Identification payloads.

Figure 13.38. The Quick Mode Exchange

The two hashes HASH1 and HASH2 authenticate the messages. HASH2 and HASH3 provide proof of liveness. HASH2 does this by including the body of the initiator's nonce, and HASH3 does it by including the bodies of both nonces.

The three hashes are calculated as

HASH1 = prf (SKEYIDa, MsgID||SA||NONCEi [||KE] [||IDi||IDr])

HASH2 = prf (SKEYIDa, MsgID|| body(NONCEi)||SA||NONCEr [||KE] [||IDi||IDr])

HASH3 = prf (SKEYIDa, 0||MsgID|| body(NONCEi)||body(NONCEr))

When perfect forward secrecy is not required, the peers generate keying material for the new SAs as

KEYMAT = prf (SKEYIDd, protocol||SPI||body(NONCEi)||body(NONCEr))

where the protocol and SPI fields are from the ISAKMP proposal that contained the Transform payload of the algorithm that requires the keying material. Because there are two values for the SPIone from each peerthe keys for the inbound and outbound SAs will be different.

Note how quickly the keying material can be generated. Four quantities are concatenated and then run through an HMAC calculation. There is no expensive, big-number arithmetic that Diffie-Hellman exponentiation required.

When perfect forward secrecy is required, the peers exchange Diffie-Hellman private keys in the Key Exchange payloads and use them to calculate the Diffie-Hellman shared secret, gxixr. This shared secret is then used to calculate the keying material as

KEYMAT = prf (SKEYIDd, gxixr||protocol||SPI||body(NONCEi)||body(NONCEr))

Once the keying material is generated, all the state associated with the phase 2 Diffie-Hellman calculations is discarded.

If additional keying material is required, the peers generate it by feeding the output of one prf calculation into another in the usual way:

K1 = prf (SKEYIDd, [gxixr|| ] protocol||SPI|| body(NONCEi)||body(NONCEr))

K2 = prf (SKEYIDd, K1|| [gxixr|| ] protocol||SPI|| body(NONCEi)||body(NONCEr))

. . .

Kn = prf (SKEYIDd, Kn-1|| [gxixr|| ] protocol||SPI|| body(NONCEi)||body(NONCEr))

KEYMAT = K1||K2|| . . . ||Kn

As usual, the individual cryptographic algorithms negotiated for the SA determine how to use the keying material to generate their keys.

As mentioned previously, a phase 2 Quick mode exchange can negotiate multiple SAs at once. This is done by merely including multiple SA payloads in the exchange, as shown in Figure 13.39.

Figure 13.39. Quick Mode with Multiple SAs

Previous Page
Next Page


Section 13.4. An Example Negotiation

13.4. An Example Negotiation

The phase 2 SAs are negotiated under the protection of the phase 1 SA, so only the ISAKMP header is visible, and we can't tell very much from looking at a network trace of those negotiations. Phase 1 negotiations, on the other hand, take place mostly in the clear, so we can watch them with a trace and follow their progress.

For debugging IPsec SA negotiations, the logs from the IKE daemon are almost always the first place to look. Where these logs are stored (if they even exist), what their names are, and what information they provide and in what format are, of course, implementation-specific details, so we won't pursue those questions any further. Nevertheless, we should not underestimate the value of learning to interpret these logs when we are debugging IPsec.

To see SA negotiation in action, let's revisit the AH transport tunnel that we built in Chapter 11. Recall that the tunnel was between bsd and laptop, as shown in Figure 11.7. On laptop, we start IPsec and dump the SAD, using the FreeBSD command setkey. We discover that there are no active SAs. Next, we ping bsd, which causes the IKE daemon to negotiate the necessary SAs. After we terminate ping, we again dump the SAD and see that there are now two AH transport mode SAs:

laptop# setkey -D
No SAD entries.
laptop# ping 192.168.123.1
PING 192.168.123.1 (192.168.123.1): 56 data bytes
64 bytes from 192.168.123.1: icmp_seq=2 ttl=64 time=0.551 ms
64 bytes from 192.168.123.1: icmp_seq=3 ttl=64 time=0.487 ms
64 bytes from 192.168.123.1: icmp_seq=4 ttl=64 time=0.487 ms
64 bytes from 192.168.123.1: icmp_seq=5 ttl=64 time=0.536 ms
^C
--- 192.168.123.1 ping statistics ---
6 packets transmitted, 4 packets received, 33% packet loss
round-trip min/avg/max/stddev = 0.487/0.515/0.551/0.029 ms
laptop# setkey -D
192.168.123.5 192.168.123.1
    ah mode=transport spi=84200268(0x0504cb4c) reqid=0(0x00000000)
    A: hmac-sha1 e6166a5b 32a65b4f 6baa95dc 7c989e2d 400f1a3c
    seq=0x00000004 replay=4 flags=0x00000000 state=mature
    created: Mar 7 18:00:01 2005 current: Mar 7 18:00:17 2005
    diff: 16(s) hard: 1800(s) soft: 1440(s)
    last: Mar 7 18:00:05 2005 hard: 0(s) soft: 0(s)
    current: 432(bytes) hard: 0(bytes) soft: 0(bytes)
    allocated: 4 hard: 0 soft: 0
    sadb_seq=1 pid=339 refcnt=2
192.168.123.1 192.168.123.5
    ah mode=transport spi=173251830(0x0a539cf6) reqid=0(0x00000000)
    A: hmac-sha1 88daa625 04dc3596 c41cdbf5 9de98243 967132a9
    seq=0x00000004 replay=4 flags=0x00000000 state=mature
    created: Mar 7 18:00:01 2005 current: Mar 7 18:00:17 2005
    diff: 16(s) hard: 1800(s) soft: 1440(s)
    last: Mar 7 18:00:05 2005 hard: 0(s) soft: 0(s)
    current: 336(bytes) hard: 0(bytes) soft: 0(bytes)
    allocated: 4 hard: 0 soft: 0
    sadb_seq=0 pid=339 refcnt=1

We capture the SA negotiation and the first ping packet with tcpdump and show the result below. We've reformatted the tcpdump output slightly:

1   18:00:00.373099 IP 192.168.123.5.isakmp > 192.168.123.1.isakmp:
      isakmp 1.0 msgid : phase 1 I agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike
                (type=lifetype value=sec)
                (type=lifeduration value=0e10)
                (type=enc value=3des)
                (type=auth value=preshared)
                (type=hash value=sha1)
                (type=group desc value=modp1024))))
    (ke: key len=128)
    (nonce: n len=16)
    (id: idtype=IPv4 protoid=udp port=500 len=4 192.168.123.5)
1.1     4500 0110 00a3 0000 4011 01e3 c0a8 7b05   E.......@.....{.
1.2     c0a8 7b01 01f4 01f4 00fc 439e 4598 0d8e   ..{.......C.E...
1.3     0b43 b113 0000 0000 0000 0000 0110 0400   .C..............
1.4     0000 0000 0000 00f4 0400 0034 0000 0001   ...........4....
1.5     0000 0001 0000 0028 0101 0001 0000 0020   .......(........
1.6     0101 0000 800b 0001 800c 0e10 8001 0005   ................
1.7     8003 0001 8002 0002 8004 0002 0a00 0084   ................
1.8     2aa6 27ab a407 e593 f013 5bbe c25f 1be4   *.'.......[.._..
1.9     fcab 63a3 348c 4fa9 4a1f 4328 155b 4ca1   ..c.4.O.J.C(.[L.
1.10    62dd d762 6808 e226 c442 adc5 545d c336   b..bh..&.B..T].6
1.11    077a e70a 16d4 f583 7b3f e014 753b ccb2   .z......{?..u;..
1.12    5357 e025 3ce8 8ea3 9572 db05 3593 5d3e   SW.%<....r..5.]>
1.13    cca8 7987 305f 016e 52c4 e70c 1dc3 82c9   ..y.0_.nR.......
1.14    0bab 06f0 ea3a 9c49 71e4 3aa7 edba 1af5   .....:.Iq.:.....
1.15    1a8e d5bd a8d6 896f 1390 5c83 360d d9fe   .......o...6...
1.16    0500 0014 c7e2 d68a 8e8f 1b55 3936 2ca0   ...........U96,.
1.17    e458 6e4b 0000 000c 0111 01f4 c0a8 7b05   .XnK..........{.
2   18:00:00.429855 IP 192.168.123.1.isakmp > 192.168.123.5.isakmp:
      isakmp 1.0 msgid : phase 1 R agg:
    (sa: doi=ipsec situation=identity
        (p: #1 protoid=isakmp transform=1
            (t: #1 id=ike
                (type=lifetype value=sec)
                (type=lifeduration value=0e10)
                (type=enc value=3des)
                (type=auth value=preshared)
                (type=hash value=sha1)
                (type=group desc value=modp1024))))
    (ke: key len=128)
    (nonce: n len=16)
    (id: idtype=IPv4 protoid=udp port=500 len=4 192.168.123.1)
    (hash: len=20)
    (vid: len=16)
2.1     4500 013c f287 0000 4011 0fd2 c0a8 7b01   E..<....@.....{.
2.2     c0a8 7b05 01f4 01f4 0128 e01c 4598 0d8e   ..{......(..E...
2.3     0b43 b113 7f1c 2f30 c56c cf66 0110 0400   .C..../0.l.f....
2.4     0000 0000 0000 0120 0400 0034 0000 0001   ...........4....
2.5     0000 0001 0000 0028 0101 0001 0000 0020   .......(........
2.6     0101 0000 800b 0001 800c 0e10 8001 0005   ................
2.7     8003 0001 8002 0002 8004 0002 0a00 0084   ................
2.8     066e e57e 3b5f 6470 53ed e233 42b7 e585   .n.~;_dpS..3B...
2.9     bb44 7b7d 7f5c b811 b424 b73a 1027 2f67   .D{}....$.:.'/g
2.10    6e23 0769 e04a f6ee a802 0971 ac90 f556   n#.i.J.....q...V
2.11    4b21 6764 c87f 3758 aea5 b267 080a d002   K!gd..7X...g....
2.12    0683 ed2a d080 e2f1 897e 1fe3 67b9 193e   ...*.....~..g..>
2.13    06e5 2676 252b 8c12 061f 6f1d fc53 90a2   ..&v%+....o..S..
2.14    e59d 8be1 aaeb 8b1b 7a5c e6e1 33c2 ae18   ........z..3...
2.15    da28 087f ec03 ac50 5188 6063 ac22 d956   .(.....PQ.'c.".V
2.16    0500 0014 b0f7 d512 2fb2 e41b 9fd1 1227   ......../......'
2.17    d795 a479 0800 000c 0111 01f4 c0a8 7b01   ...y..........{.
2.18    0d00 0018 6d70 6043 8779 6e0d 4963 01cf   ....mp'C.yn.Ic..
2.19    e803 cac4 aa13 ccb5 0000 0014 7003 cbc1   ............p...
2.20    097d be9c 2600 ba69 83bc 8b35             .}..&..i...5
3   18:00:00.492011 IP 192.168.123.5.isakmp > 192.168.123.1.isakmp:
      isakmp 1.0 msgid : phase 1 I agg:
    (hash: len=20)
3.1     4500 0050 00a4 0000 4011 02a2 c0a8 7b05    E..P....@.....{.
3.2     c0a8 7b01 01f4 01f4 003c 6346 4598 0d8e    ..{......<cFE...
3.3     0b43 b113 7f1c 2f30 c56c cf66 0810 0400    .C..../0.l.f....
3.4     0000 0000 0000 0034 0000 0018 7aa7 7e5d    .......4....z.~]
3.5     9a54 8e4c 59cb d0ea cca1 177b 79f5 1788    .T.LY......{y...
4   18:00:00.493857 IP 192.168.123.1.isakmp > 192.168.123.5.isakmp:
      isakmp 1.0 msgid : phase 2/others R inf[E]:
      [encrypted hash]
5   18:00:01.526554 IP 192.168.123.5.isakmp > 192.168.123.1.isakmp:
      isakmp 1.0 msgid : phase 2/others I oakley-quick[E]:
      [encrypted hash]
6   18:00:01.541429 IP 192.168.123.1.isakmp > 192.168.123.5.isakmp:
      isakmp 1.0 msgid : phase 2/others R oakley-quick[E]:
      [encrypted hash]
7   18:00:01.548966 IP 192.168.123.5.isakmp > 192.168.123.1.isakmp:
      isakmp 1.0 msgid : phase 2/others I oakley-quick[E]:
      [encrypted hash]
8   18:00:02.334647 IP 192.168.123.5 > 192.168.123.1:
      AH(spi=0x0504cb4c,sumlen=16,seq=0x1): icmp 64:
      echo request seq 512

In line 1, we see a breakout of the first message in the phase 1 negotiation. Notice that this is an Aggressive mode (agg) negotiation. The first payload is the SA offer (sa:) with a single Proposal payload (p:), which in turn has a single Transform payload (t:). The Transform payload has six attributes that describe the SA's lifetime, encryption algorithm, authentication method, integrity method, and Diffie-Hellman group. After the SA payload, are the Key, Nonce, and Identification payloads.

Let's examine the packet itself to see how this data is carried in the message. Lines 1.1 and 1.2 contain the IP and UDP headers. On lines 1.21.4, we see the ISAKMP header set in boldface. As we see from Figure 13.1, the first 16 bytes are the initiator and responder cookies. Notice that the responder cookie is 0 in the first message, as expected. The next byte (0x01) tells us that the next payload is an SA payload (see Figure 13.2), followed by the major and minor version (0x10) and the exchange type (0x04). From Figure 13.3, we see that this is an Aggressive mode exchange. The next byte is the flags; as we see, no flags are set. The next 8 bytes are the message ID (0) and the length of 244 (0xf4).

On lines 1.4 and 1.5, we see the SA payload:

1.4     0000 0000 0000 0120 0400 0034 0000 0001   ...........4....
1.5     0000 0001 0000 0028 0101 0001 0000 0020   .......(........

Notice from Figure 13.6 that the next header field (0x04) is a Key Exchange payload, not the Proposal payload, which comes next but is considered part of the SA payload. The second 4 bytes are the DOI, which is IPSEC (1). The last 4 bytes of the SA payload proper are the situation, which in this case is SIT_IDENTITY_ONLY.

Following the SA payload is the Proposal payload on line 1.5. The format of this payload was shown in Figure 13.7.

1.5     0000 0001 0000 0028 0101 0001 0000 0020   .......(........

The length of 40 (0x28) includes the following Transform payload, just as the SA payload length field included the Proposal and Transform payloads' lengths. Also, the next payload field is NONE (0), even though there is a following Transform payload. If there were another Proposal in the SA payload, this field would be set to Proposal (2). The proposal ID in the fifth byte is 1, as we saw in line 1. The protocol ID (in the sixth byte) is a 1, indicating ISAKMP (see Figure 13.8). The seventh byte is the SPI size. Because this is 0, the SPI field is not present in the payload. Recall that the SPI for phase 1 SAs is the two cookies. Finally, the last byte tells us that there is one Transform payload for this proposal, shown on lines 1.51.7:

1.5     0000 0001 0000 0028 0101 0001 0000 0020   .......(........
1.6     0101 0000 800b 0001 800c 0e10 8001 0005   ................
1.7     8003 0001 8002 0002 8004 0002 0a00 0084   ................

As we see from Figure 13.9, most of the information in a Transform payload is carried in the attributes. We see from the first 2 bytes on line 1.6 that this is transform 1 and that the transform ID is IKE (1)see Figure 13.10. The remaining bytes in the payload are the attributes. For example, the first attribute (on line 1.6) is 800b 0001. Because the AF bit is set (see Figure 13.5), this is a basic attribute, and its value is carried in the second 2 bytes. From Figure 13.11, we see that attribute 11 (0x000b) is the lifetime type for this SA. From the IKE specification (RFC 2409), we see that a value of 1 is seconds. The next attribute, 800c 0e10, is the lifetime duration attribute, which tells us how many seconds the SA should live before being replaced. Note from Figure 13.11 that this is a variable attribute but that because the value fits in 16 bits, it was encoded as a basic attribute instead. The lifetime is 3,600 (0xe10) seconds, or 1 hour. The other attributes are similar, and we can see what they are from line 1.

The Key Exchange payload is on lines 1.71.15. Its generic header is the last 4 bytes on line 1.7. The rest of the payload is the key-exchange data. Its length is 132 (0x84), but tcpdump shows the length of the data as only (128), instead of the total length.

The Nonce payload on lines 1.16 and 1.17 is similar. It consists of a generic header and 16 bytes of nonce. Its next payload is set to Identification payload (5).

The Identification payload appears on line 1.17:

1.17    e458 6e4b 0000 000c 0111 01f4 c0a8 7b05   .XnK..........{.

Its next payload field is set to NONE (0), indicating that this is the last payload. The fifth byte (0x01) is the identification type. From the DOI (RFC 2407), this specifies that the identification is an IPv4 address. The protocol ID is 17 (0x11), indicating UDP (Figure 2.12), and the port is the default value of 500 (0x1f4). The initiator's IP address is 192.168.123.5 (0xc0a87b05), as expected.

The other two phase 1 messages are similar. Exercise 13.11 asks us to perform a similar analysis on them. The phase 2 Quick mode messages are encrypted, so we can't see their contents. On line 8, we see the AH protected ping that initiated the negotiation we have been studying.


Section 13.5. Summary

13.5. Summary

In this chapter, we explored ISAKMP and IKE, the mechanism by which IPsec negotiates security associations and exchanges keying material. Although these SAs can be configured by hand, manual keying does not scale well and is subject to the security shortcomings that long-lived keys always suffer from.

We began by observing that IKE, the Internet Key Exchange protocol, is a hybrid of three other protocols: ISAKMP, OAKLEY, and SKEME. ISAKMP provides the infrastructure on which we can build a variety of key-exchange protocols. OAKLEY and SKEME contribute exchange modes and authentication methods to IKE. In addition, the original four Diffie-Hellman groups that IKE uses, the OAKLEY groups, come from OAKLEY.

Before we could study and understand IKE, we had to examine the ISAKMP message formats, payload types, and exchange modes. ISAKMP works in two phases. In the first phase, an ISAKMP SA is negotiated. The SA provides an encrypted and authenticated channel over which the second phase negotiates the IPsec SAs that are used by AH and ESP.

In addition to negotiating the SAs and handling the key exchange, IKE authenticates each peer to the other. This ensures that each node can be sure of the identity of its peer. There are four ways to do this authentication: shared secrets, digital signatures, public key encryption of nonces, and revised public key encryption of nonces. As we saw, these methods all have their advantages and disadvantages.

In the event that the peers are acting as proxies and negotiating SAs for client hosts, they can, in Main mode, hide the identity of those hosts. This ability is missing in Aggressive mode, but this mode has the advantage of using only half the messages required by Main mode.

The fundamental method that ISAKMP and IKE use to establish a secure channel is to exchange Diffie-Hellman private keys from which they derive a shared secret. This shared secret, in turn, is combined with a nonce from each peer, and other parameters from the exchange, and run through an HMAC calculation to generate keying material for the cryptographic algorithms. Each of the algorithms uses this material in an algorithm-specific manner to generate its keys.

After phase 1 is completed, either peer can initiate a New Group exchange to negotiate a different Diffie-Hellman group for future SAs. The new group can be specified either by its identifierin the case of the predefined groupsor by the group attributes for new groups.

Quick mode, the phase 2 exchange mode, can generate keys very quickly by combining the Diffie-Hellman shared secret from phase 1 with nonces exchanged in phase 2. This method has the advantage of not requiring expensive big-number exponentiations, but it can't provide perfect forward secrecy. If Key Exchange payloads are included in the Quick mode exchange, perfect forward secrecy is provided at the cost of the Diffie-Hellman exponentiations.

We concluded the chapter with an example of an Aggressive mode IKE negotiation using shared secret authentication. We performed a fairly complete analysis of one of the messages, showing how the various payloads are combined to form the initiator's message. We were not able to do a similar analysis on the phase 2 messages, because they are encrypted, and only the ISAKMP header is visible to us.


Exercises

13.1 | Why do the ISAKMP payloads need a next payload field?
13.2 | Is the CONNECTED notification message an ISAKMP or an IPsec message?
13.3 | Consider the case of a mobile host with a nonfixed IP address using Main mode with shared-secret authentication to negotiate an SA with a security gateway. Why doesn't the mobile host have the same problem with Main mode that the security gateway does?
13.4 | What is the quantity gxixr in the calculation of SKEYID for the authentication with digital signatures method and the calculations of the quantities SKEYIDd, SKEYIDa, and SKEYIDe?
13.5 | In IKE Aggressive mode, the Authentication payload is optionally encrypted. How does the responder know whether it's encrypted?
13.6 | Does Main mode with signature authentication have the same problem with mobile hosts and dynamic IP addresses that Main mode with shared-secret authentication has? Why or why not?
13.7 | How does authentication with signatures guarantee that the state variables were not tampered with in transport? How does it authenticate each node to its peer?
13.8 | Does authentication with a preshared key offer the same repudiation as authentication with public key encryption?
13.9 | In the final analysis, both authentication with public key encryption and authentication with digital signatures use public key cryptography to authenticate the peers. Why doesn't authentication with digital signatures offer repudiation?
13.10 | What is the responder's cookie in the sample negotiation of Section 13.4?
13.11 | Perform an analysis of the second and third phase 1 messages from the sample negotiation of Section 13.4 similar to that we performed of the first message.
13.12 | In Section 13.4, we showed the results of pinging through an AH transport mode tunnel. We terminated ping after six requests had been sent, but we received only four replies. Given that this experiment was performed on a LAN, why did we lose the two packets?


Chapter 14. IPsec Futures

    Section 14.1. Introduction

    Section 14.2. IPsec Architecture

    Section 14.3. AH

    Section 14.4. ESP

    Section 14.5. IKE

    Section 14.6. NAT Traversal

    Section 14.7. Summary

    Exercises


Section 14.1. Introduction

14.1. Introduction

At the time of this writing (early 2005), the IPsec Working Group is developing specifications for new versions of AH, ESP, and IKE. Although these specifications are still in the Internet Draft stage, they are nearing completion and will soon become RFCs. We can expect that the final versions of these protocols will be essentially as described in this chapter.

Because the specifications are not yet in final form, and because it will likely take some time for implementations to appear and be deployed, we do not describe them in the same detail as we have the current versions. Rather, we discuss how they differ from today's versions and what additional problems they solve.

For reference, our discussion is based on the following drafts:

Architecture | draft-ietf-ipsec-rfc2401bis-05.txt
AH | draft-ietf-ipsec-rfc2402bis-11.txt
ESP | draft-ietf-ipsec-esp-v3-10.txt
IKE | draft-ietf-ipsec-ikev2-17.txt

We also discuss NAT Traversal (NAT-T), a method of easing the interoperability problems between NAT and IPsec. The NAT-T specifications, RFC 3947 [Kivinen, Swander, Huttunen, and Volpe 2005] and RFC 3948 [Huttunen, Swander et al. 2005], were released in January 2005, so implementations should start appearing soon. We discuss NAT-T in detail and see how it can overcome most of the problems that IPsec has when running in an environment that includes NAT.


Section 14.2. IPsec Architecture

14.2. IPsec Architecture

The current IPsec architecture is specified in RFC 2401 [Kent and Atkinson 1998c]; we refer to the replacement described in the RFC 2401bis draft as the new architecture. Although many of the details in the new architecture differ from the current version, the fundamental ideas and underlying principles remain the same.

The IPsec Processing Model

In the new architecture, the SPD selection and routing functions are separated; consequently, SPD entries are no longer associated with an interface. This means that for uni-cast packets, the meaning of the security parameter index (SPI) no longer depends on the destination address. Whether the SPI's meaning depends on the IPsec protocol is a local matter; an implementation can use a single number space for both AH and ESP, or it can use separate number spaces for each.

Implementations are no longer required to support nesting or SA bundles but are still free to do so. The new specification describes a method of achieving the same results through entries in the SPD and forwarding tables.

IPsec is now allowed to process fragmented IPv4but not IPv6tunnel-mode packets. The new architecture specifies several methods for dealing with fragments, and fields supporting this are now required in the SPD.

Finally, AH support is no longer required, but implementations are free to provide it. This recognizes the fact that although in almost all cases, the ESP-provided integrity is sufficient, in a small number of contexts, the extra protection that AH provides is useful.

The Security Policy Database

In the new architecture, the function and form of the SPD are specified much more precisely than in RFC 2401. Recall from Chapter 10 that the SPD describes the processing to be applied to each packet by matching selectors in the packet with selectors in the SPD. Also recall that the SPD is ordered so that the more specific of overlapping policies will be applied before the more general.

In the new architecture, the SPD conceptually consists of three disjoint but interleaved parts:

SPD-I | The entries that describe the inbound traffic that should be discarded or bypass IPsec
SPD-O | The entries that describe the outbound traffic that should be discarded or bypass IPsec
SPD-S | The entries that describe traffic to which IPsec should be applied

The disposition of inbound traffic is specified in either the SPD-I or the SPD-S. Similarly, the disposition of outbound traffic is specified in either the SPD-O or the SPD-S. We could, for example, describe outbound processing as checking the SPD-O to see whether a packet should be discarded or bypass IPsec and then checking the SPD-S if no matching entry is found in the SPD-O.

The new architecture envisions that caches will be associated with each of the three parts of the SPD. For example, when a packet first matches an SPD-O entry, the entry will be placed in the SPD-O cache. The rationale is that using the caches would improve IPsec's performance.

Unfortunately, the ordering of the SPD can cause problems with using caches this way. Suppose, for example, that a more general overlapping entry is cached, but the more specific is not. If a packet matching the more specific policy is presented for processing, IPsec will find the incorrectthat is, more generalcached entry and perform the wrong action on the packet. To solve this problem, the new architecture includes a method for decorrelating the SPD entriesthat is, for removing overlapping policies by breaking them into multiple disjoint policies.

An example will make this clear. Suppose we have the following two policies.

  1. Traffic to 192.168.1.10 should have ESP applied.

  2. Traffic to 192.168.1.1 through 192.168.1.200 should be discarded.

Notice that the order is important because if policy 2 were checked first, traffic to 192.168.1.10 would be discarded instead of having ESP applied. To decorrelate these entries, we transform the second policy into two policies, neither of which overlaps the first policy:

1. Traffic to 192.168.1.10 should have ESP applied.

2a. Traffic to 192.168.1.1 through 192.168.1.9 should be discarded.

2b. Traffic to 192.168.1.11 through 192.168.1.200 should be discarded.

Notice that in this case, we can check the policies in any order without ambiguity. In particular, we can add these decorrelated policies to the caches without fear of mishandling a packet.

Traffic Selectors

The new architecture SPD is enhanced to allow more flexible packet handling. Selectors are now specified as lists of ranges. For example, we can specify that a policy should apply to destination addresses 192.168.1.1-192.168.1.13, 192.168.1.25-192.168.1.100, and 10.1.0.1-10.1.0.50. Single addresses are expressed as a trivial range. Ports can be specified in the same way, so in the new architecture, we can specify port ranges.

For ICMP packets, we can specify the type and code fields (Figure 2.24) instead of a port, so we have increased granularity for these packets. Similarly, we can specify the IPv6 mobility header (MH) type as a policy selector.

See RFC 3775 [Johnson, Perkins, and Arkko 2004] for a discussion of the IPv6 mobility header.

In addition to the selectors, the SPD indicates the mode (transport or tunnel), the local and remote tunnel addresses for tunnel mode, whether the SA should use extended 64-bit sequence numbers, the IPsec protocol (AH or ESP), cryptographic algorithms, some flags specifying how to handle fragments and the differentiated service bits, and the populate from packet (PFP) flags that specify whether the SA should use the selector from the packet or from the SPD.

The PFP flags are a generalization of the RFC 2401 ability to generate multiple SAs from the same policy entry. For example, if one of the policy selectors specified a destination address of 192.168.1.1-192.168.1.50 and if the PFP flag were set for the destination address, a separate SA would be negotiated for any of the 50 destination addresses for which IPsec sees a packet. If the PFP flag is not set, the same SA would be used for all 50 destination addresses.

There are PFP flags for

  • The local address

  • The remote address

  • The next-layer protocol

  • The local port, ICMP type/code field, or MH type

  • The remote port, ICMP type/code field, or MH type

Support for Multicast

The new architecture supports multicast and anycast as well as unicast packets. As discussed above, the SPI or perhaps the SPI and the IPsec protocol are sufficient to locate the SA for an incoming unicast packet. Because a third party, rather than the destination host, usually supplies the SPI for multicast packets, a collision with a host-generated SPI is possible, and further steps are required to avoid ambiguity.

An IPsec-protected single-source multicast group packet is specified by the source address, destination address, and SPI, so these three quantities are consulted to determine the appropriate SA. In the case of a multisource multicast group, only the destination address and SPI are used to specify the SA. Thus, there are three ways of mapping an IPsec packet to its SA, and we must have some way of ensuring that we do this in an unambiguous way.

The new architecture accomplishes this by using a "longest match" rule. When processing an incoming packet, IPsec first searches the SAD for a match on the SPI and source and destination addresses. If there is no match, the SAD is searched again, looking for a match on destination address and SPI. If there is still no match, the SAD is searched for a matching SPI. If this last search also fails, there is no SA for this packet, and the packet is dropped.

The Peer Authorization Database

The new architecture adds a third database, the peer authorization database (PAD), to the SPD and SAD. The PAD is used to tie together IKE and the SPD. It contains information on which peers are allowed to negotiate AH or ESP SAs with the host.

As an example, consider a mobile host that establishes a VPN with a security gateway on its home network from many different IP addresses. In this case, it is obviously not possible to simply use the mobile host's source address to locate the proper policy or check whether it's authorized. Instead, the mobile host sends identifying information in the Identity payload, which the security gateway uses to check authorization and to locate an appropriate policy.

The PAD also includes information on the method of identity authorizationshared secret, digital signature, and so onthat the responder should use to verify the identity of the initiator. If certificates are involved, the PAD contains information on acceptable root certificates and revocation lists.

In short, the PAD contains the information that the responder needs to execute the authorization protocol with an initiator. The PAD may be notional in the sense that its functions are part of the SA management softwareIKE or the equivalentand that no distinct database exists. Whether or not the PAD exists as a distinct database is a local matter. The new architecture uses it as the (possibly notional) locus of information needed to perform initiator authorization and to locate the appropriate SPD entries.


Section 14.3. AH

14.3. AH

As noted in our discussion of the new IPsec architecture, AH is no longer a mandatory protocol. Other than that, the main changes from RFC 2402 [Kent and Atkinson 1998a] are the new SPI processing, discussed in the previous section, and the new processing required to deal with the 64-bit extended sequence numbers. The AH header (Figure 11.2) remains unchanged from RFC 2402, so the on-the-wire behavior of AH is essentially the same as before.

As we discussed in Chapter 11, it is critical that the sequence number not be allowed to wrap when antireplay protection is enabled. When sequence number wrapping is imminent, IPsec invokes IKE to negotiate a new SA. Because the new SA would have a new SPI and new keys, an attacker could not replay old packets with the same sequence number.

In very high speed connections, the 32-bit sequence number can wrap frequently and therefore cause frequent renegotiation of SAs. To alleviate this problem, IPsec can use a 64-bit extended sequence number (ESN) for AH and ESP. As we'll see later, IKEv2 negotiates whether an SA will use normal 32-bit sequence numbers or the extended 64-bit sequence numbers.

To save bandwidth and keep the AH header unchanged, only the lower 32 bits of an ESN are transmitted in the AH packet. The two peers maintain separate versions of the entire 64-bit sequence number counter and keep them synchronized as described next. In order to guarantee that a packet is not a replay, the receiver must ensure that its value of the ESN is the same as the sender'sthat is, that the untransmitted upper 32 bits of the ESN are the same as the sender's.

In order to keep the peers' ESN counters synchronized, the sender includes the upper 32 bits in the ICV for the packet. That is, the data used to compute the MAC includes the upper 32 bits. This does not add to the length of the AH packet, of course.

Let's briefly examine how to perform the antireplay check. We use the same antireplay window technique that we discussed in Chapter 11. As before, the specification mandates that this window be at least 32 sequence numbers wide and recommends that it be 64 sequence numbers wide by default. The specification also recommends that the window size be configurable so that it can be increased for high-speed connections.

First, let us assume that a connection will drop or lose no more than 232 - 1 consecutive packets. In the very unlikely event that this happens, we must take special action to resynchronize the counters. We discuss that procedure shortly.

There are two cases to consider. In the first case, every sequence number in the window has the same upper 32 bits. In the second case, the value of the upper 32 bits increases by 1 at some packet in the window. Case 1 is straightforward. If the packet's sequence number is to the right of the window, we assume that the sequence number check succeeded, and we update the window in the usual way. If, in fact, the upper 32 bits differ, the packet will fail the ICV check and be rejected anyway.

Similarly, if the packet's sequence number falls within the window, we accept or reject it, depending on whether it is marked as already received. Again, if the upper 32 bits differ, the packet will be rejected by the ICV check.

Finally, if the packet lies to the left of the window, we tentatively assume that the counter's lower 32 bits have wrapped and that the upper 32 bits have increased by 1. If the packet passes the ICV check, these assumptions are confirmed, and we update the antireplay window and ESN counter appropriately. If the ICV check fails, we reject the packet and leave the sequence number state as it was.

In the second case, the window straddles a point in the ESN number space where the lower 32 bits wrapped, so packets within the window can have differing values for the upper 32 bits. The antireplay check in this case is similar to the preceding one, but the details are a little fussier because we have to track which value of the upper 32 bits to use (see Exercise 14.1). The complete details are in Appendix B of the AH and ESP drafts.

If 232 or more consecutive packets are lost, the peers lose synchronization of the upper 32 bits. This presents two problems: First, the peers must detect that their ESN counters have become desynchronized; second, they must resynchronize them. The recommended solutions for these problems are as follows. A host counts the number of consecutive packets that fail the ICV check. When this number exceeds some configured threshold, the receiver assumes that its and its peer's ESN have become desynchronized.

To resynchronize, the receiver selects one of the packets that failed the ICV check and retries it by successively incrementing the value of the upper 32 bits. If the packet authenticates with one of these trial values, that value is assumed to be the correct value for the upper 32 bits, and the sequence number state is adjusted to reflect that. To prevent an old or forged packet from causing this process to run away, the receiver should limit the number of trial values that it checks.

Recall that antireplay checking is optional and that the receiver can choose to disable it. Note, however, that when the ESN option is enabled, antireplay should be too, because the antireplay algorithms are what keep the ESN counters synchronized. In any event, specifying ESN without antireplay makes little sense, because the point of sequence numbers is the antireplay check.


Section 14.4. ESP

14.4. ESP

Like AH, the new version of ESP is very similar to the old (ESPv2) as specified in RFC 2406 [Kent and Atkinson 1998b]. In particular, if one of the new combined-mode cryptographic algorithms (see the next subsection) is not in use, the packet format is the same as it was for ESPv2 (Figure 12.1). On the other hand, there are enough differences, including in some cases the on-the-wire packet format, that the new version is called ESPv3.

Just as with AH, ESPv3 supports the new SPI semantics and optional extended 64-bit sequence numbers (ESN). When ESN is enabled, ESP uses the same antireplay mechanisms that AH does.

Combined-Mode Cryptographic Algorithms

Combined encryption/authentication algorithms can increase performance by providing confidentiality and authentication with a single pass over the data. Such algorithms may or may not require that an explicit ICV be appended, so it is possible that the authentication data field of Figure 12.1 is not present in a packet protected by a combined-mode algorithm.

Combined-mode algorithms may also have other problems. For example, if ESN is enabled, the upper 32 bits are not present in the packet, so it may not be possible to include them in the authentication calculations. In that case, the high-order bits of the ESN counter may have to be added to the packet explicitly. Similarly, the SPI and sequence number fields from Figure 12.1 are included in the authentication calculation, so they too may have to be replicated in the encrypted part of the packet.

These considerations dictate that combined-mode algorithm packets must be processed differently from packets that use separate algorithms. Because the details will vary with the particular combined-mode algorithm, these details must be defined in the specification for that algorithm, and each algorithm must provide facilities to implement those details.

Optional Padding and Dummy Packets

As we discussed in Chapter 12, tunnel-mode ESP can provide a limited amount of protection from traffic analysis. Although up to 255 bytes of padding can be added to a packet, this padding is intended to fill out encryption blocks and provide alignment. The amount of padding is not adequate to effectively hide the payload size. To remedy this, ESPv3 provides two additional mechanisms that make traffic analysis more difficult.

The first mechanism is called traffic flow confidentiality (TFC). TFC allows an arbitrary number of bytes to be added just before the encryption/alignment padding, as shown in Figure 14.1.

Figure 14.1. The ESPv3 Packet

[View full size image]

Notice that there is no field that specifies the length of the TFC padding. This means that the receiver must have some way of determining this length in order to discard it. With tunnel mode, the total length field from the IP header (Figure 2.11) can be used to determine the TFC length. For transport mode, the length can sometimes be determined from the upper-layer protocol length field. This is the case with UDP (Figure 2.14) and ICMP (Figure 2.22) but not with TCP (Figure 2.16), which does not carry the total length of the TCP segment in its header.

The second mechanism that ESPv3 provides to fight traffic analysis is the dummy packet. ESP can generate and transmit dummy packets, which the receiver discards without further processing. Dummy packets are identified by a protocol ID of 59 in the ESP next header field. The SPI, sequence number, next header, padding, pad length, and ICV fields must be present so that IPsec can authenticate and decrypt the packet before discovering that it's a dummy packet. The data portion of the packet contains arbitrary data.

The intention is that these packets will be transmitted at random intervals to obscure the traffic flow. The optimal strategy for generating the dummy packets depends on the traffic they are intended to protect and is a local matter.


Section 14.5. IKE

14.5. IKE

The most significant changes in the new protocols are in IKE. IKEv2 is considerably different from the first version, which we discussed in Chapter 13. As we'll see, the SA establishment protocol is considerably simplified. At the same time, IKEv2 has significantly enhanced capabilities to negotiate fine-grained SAs in a reliable manner.

IKEv2 exchanges consist of two messages: a request and a response. The sender of the request provides reliability by implementing a TCP-like retransmission strategy. The default behavior is for a node to send a request and wait for the response, but messages are sequenced, so the peers can agree to multiplex several exchanges onto a single SA at the same time.

IKE Messages

IKEv2 messages are formed almost exactly as they were in IKEv1. Each message begins with an IKE header that has the same format (see Figure 13.1) that it did in IKEv1, except that the initiator and responder cookies are renamed the initiator and responder SPIs.

Following the header are one or more IKE payloads, each of which begins with a generic header, just as in IKEv1. The IKEv2 generic header is the same as in IKEv1 (see Figure 13.4), except that a critical bit has been added at bit 8 to indicate that the responder must recognize this payload. Although we won't discuss the payload formats in detail, most of them have, and are similar to, an IKEv1 equivalent.

IKE Exchanges

Recall from Chapter 13 that IKEv1 had eight possible exchange sequences that it could use to establish an IKE SA. After the IKE SA was in place, a three-message quick exchange was needed to establish a phase 2 SA. In IKEv2, the process of establishing these SAs is considerably simplified.

IKEv2 uses three exchange types to negotiate SAs:

IKE_SA_INIT | This is the initial exchange, in which the peers establish a secure channel. After the IKE_SA_INIT exchange, all further exchanges are encrypted.
IKE_AUTH | This is the second exchange, in which the peers authenticate themselves to each other and create the first child SA, a phase 2 SA in IKEv1 terminology.
CREATE_CHILD_SA | This exchange is used to create additional child SAs. It serves the same function that the Quick mode exchange does in IKEv1.

Each of these exchanges is only two messages, so the process of establishing an IKE SA and its first child SA involves only four messages. Each additional child SA takes two messages. Note that IKEv2 no longer speaks of phase 1 and 2 SAs; instead, it uses the terms IKE SA and child SA.

Let's see how IKE uses these exchanges to negotiate SAs. Figure 14.2 shows the normal IKE_SA_INIT/IKE_AUTH exchange sequence that establishes an IKE SA and its first child SA. In the typical case of a single ESP tunnel between two nodes, this is all that is required to establish the VPN. The first two messages are the IKE_SA_INIT exchange. The peers exchange keying material and nonces in the KE and NONCE payloads and negotiate IKE SA encryption and authentication parameters in the SA1 payloads. The responder can request a certificate from the initiator by including the optional CERTREQ payload. If it wants a certificate from the responder, the initiator will request it in the IKE_AUTH exchange.

Figure 14.2. The IKE_SA_INIT and IKE_AUTH Exchanges

[View full size image]

The second two messages are the IKE_AUTH exchange. The two peers exchange their identities in the Identification (ID) payloads and authenticate them with data carried in the AUTH payloads. The exact data in the AUTH payload depends on the authentication method. If the responder has more than one identity, the initiator can indicate which identity it wishes to use, by including the IDr payload in its IKE_AUTH message. Except for the header, everything is encrypted in the IKE_AUTH message.

We are using the same convention as in Chapter 13: Payloads that are encrypted are set in italics.

The SA2, TSi, and TSr payloads are used to negotiate the child SA. The SA2 payloads negotiate the IPsec protocol and the cryptographic primitives that it will use. Unlike IKEv1, the traffic selectors are not specified in the SA payload but are specified in their own TSi and TSr payloads.

Also unlike IKEv1, the generation of keying material does not depend on the type of peer authentication that is used. One of the cryptographic primitives negotiated in the SA1 payloads is a pseudorandom function prf(K, M). This, in turn, is used to define the iterative function prf*(K, M) as

prf*(K, M) = T1||T2|| . . . ||Tn

where

T1 = prf (K, M ||0x01)

T2 = prf (K, T1||M||0x02)

. . .

Tn = prf (K, Tn-1||M||n)

Keying material for the IKE SA is generated by first calculating the quantity KEYSEED as

KEYSEED = prf(NONCEi||NONCEr, gxixr)

where gxixr is the Diffie-Hellman shared secret calculated from the Key Exchange payloads. Next, a long string of bits, KEYMAT, is generated by

KEYMAT = prf*(KEYSEED, NONCEi||NONCEr||SPIi||SPIr)

and keying material for the authentication, encryption, and integrity algorithms is extracted from this string. A seed for further keying material, SKd, is also extracted from KEYMAT.

Keying material for the first child SA is generated in a similar way, using SKd instead of KEYSEED:

KEYMAT = prf*(SKd, NONCEi||NONCEr)

where the nonces are from the IKE_SA_INIT exchange.

IKEv2 has three methods for the peers to authenticate their identities. Two of these methods involve having the peers sign selected data from the exchanges. The peers may do this using the prf and a shared secret, or they can use one of the common signature methods, such as DSA or RSA.

The third method is to use the Extensible Authentication Protocol (EAP). In general, EAP is more complicated and will involve the exchange of additional messages, but it provides a general framework into which new authentication methods can be added without changing the IKEv2 protocol. EAP is specified in RFC 3748 [Aboba, Blunk, Vollbrecht et al. 2004].

If additional child SAs are required or if the IKE SA or one of the child SAs needs to be rekeyed, the peers execute a CREATE_CHILD_SA exchange. Figure 14.3 shows the CREATE_CHILD_SA exchange.

Figure 14.3. The CREATE_CHILD_SA Exchange

If the exchange is to rekey an existing SA, the first payload must be a Notify payload, N, that specifies which SA is being rekeyed. If a new child SA is being negotiated, the N payload must not be present.

For perfect forward secrecy, the peers can include the optional Key Exchange payloads in the exchange. In this case, the new keying material will be generated by

KEYMAT = prf*(SKd, gxixr||NONCEi||NONCEr)

where the gxixr is the new Diffie-Hellman shared secret from the exchange. The nonces are from the current exchange. If perfect forward secrecy is not required, the new keying material is generated the same way except that the Diffie-Hellman shared secret is not concatenated to the nonces.

There are two other types of exchanges. The first is used to help prevent denial-of-service attacks. The rationale for this exchange is much like the cookie exchange from IKEv1. An attacker can send dummy IKE_SA_INIT requests with a forged source address, forcing the responder to perform expensive Diffie-Hellman calculations for its response. If the responder notices that it has several half-completed IKE SAs, it can insist that its peer prove that it is reachable at its source address by sending a Notify payload containing a cookie instead of the response to the IKE_SA_INIT request. The requester then repeats its request, including the Notify payload with the cookie. Figure 14.4 shows the exchanges.

Figure 14.4. The Initial Exchange with a Cookie

[View full size image]

The HDR(x,y) notation shows the contents of the SPIs in the header: I indicates the initiator's SPI and R the responder's SPI; 0 indicates the SPI has not been determined yet.

The other exchange is the INFORMATIONAL exchange. Like all IKEv2 exchanges, each INFORMATIONAL exchange request expects a response. Three types of payloads can be included in an INFORMATIONAL exchange. Any number of any combination of payloads can be included, as shown in Figure 14.5.

Figure 14.5. The INFORMATIONAL Exchange

We've already seen the Notify payload (N) in conjunction with cookies. There are several other types as well. They carry error and status information, much as they do in IKEv1. The Delete payload (D) informs the peer that the sender has deleted one or more of its incoming SAs. The responder is expected to delete those SAs as well and will usually include Delete payloads for the corresponding SAs in the other direction in its response message.

The Configuration payload (CP) is used to negotiate configuration data between the peers. One important use of the CP payload is to request (request) and assign (response) an address on a network protected by a security gateway. In the typical case, a mobile host will establish a VPN with a security gateway on its home network and will request that it be given an IP address on the home network. Notice that this eliminates one of the problems that the combined use of L2TP and IPsec (Chapter 5) is intended to solve.

IKEv2 is a very rich protocol, and we have looked only at some of its more important features here. IKEv2 is intended to simplify the key-management function in IPsec, to add new flexibility in negotiating SAs, and to solve some of the problems in IKEv1.


Section 14.6. NAT Traversal

14.6. NAT Traversal

We have already seen several instances of interactions between IPsec and NAT/PAT that result in operability problems.

In this section, we use "NAT" to mean both NAT and PAT. We use "PAT" when we want to make it clear that we are concerned with the port-remapping aspects of NAT/PAT.

RFC 3715 [Aboba and Dixon 2004] discusses these problems at length and remarks that attempts to solve them with NAT alone have not been completely successful and in some cases have made the problems worse. In this section, we discuss a relatively new solution, NAT-Traversal (NAT-T) that addresses many of these issues.

Most of the interoperability difficulties between IPsec and NAT involve one or more of the following facts.

  • AH authenticates the source IP address and ports and thus prevents NAT from changing them.

  • With ESP, TCP and UDP ports are authenticated and protected, and therefore PA T cannot remap the source port.

  • TCP/UDP checksums depend, through the pseudoheader, on the source and destination addresses. When NAT changes these addresses, the TCP/UDP checksums are invalidated. Because the checksums are authenticated and/or encrypted, NAT cannot recalculate them.

Because not much can be done about the first problem, NAT-T concerns itself only with ESP and IKE. Even with ESP, some common situations don't have a good solution. We look at a couple of these problem areas after we discuss the operation of NAT-T. As we'll see shortly, IPsec peers negotiate the use of NAT-T through IKE.

UDP Encapsulation of ESP and IKE

When NAT-T is used, ESP packets, whether in transport or tunnel mode, are encapsulated in UDP packets, as shown in Figure 14.6. The utility of this encapsulation is immediately clear when we consider that PAT now has an unprotected source port that it can remap.

Figure 14.6. ESP UDP Encapsulation

[View full size image]

RFC 3948 [Huttunen, Swander et al. 2005] specifies that the UDP checksum should be disabled by setting the checksum field to 0 and that this traffic should be sent on the same source and destination port that is used for IKE traffic. The source and destination ports are normally set to 4500, but the source port is subject to remapping by PAT. That means that the peer of a node behind a NAT must send its UDP packets to the remapped port instead of to port 4500.

NAT Keep-Alives

One of the problems that can occur when IPsec and NAT are used together is that the NAT mapping may time out if there is no traffic for a while. To prevent this, an IPsec node behind a NAT must ensure that the connection is not idle for longer than the NAT timeout threshold. The IPsec node does this by periodically sending keep-alive packets to its peer, using the same source and destination ports as the ESP and IKE traffic use.

The keep-alive packets are a normal UDP packet with a single byte of 0xff as the payload. A peer receiving a keep-alive packet ignores it, because its only purpose is to prevent the sender's NAT from timing out. As with the encapsulated ESP packet, RFC 3948 specifies that the checksum should be disabled.

IKE and NAT-T

As mentioned earlier, the use of NAT-T is negotiated by IKE. Both peers must support NAT-T for this to happen, of course, so they inform each other of their willingness to engage in NAT-T negotiations, by means of Vendor ID payloads, which they send in the first two messages of a phase 1 negotiation. The content of the Vendor ID payload is the MD5 hash of "RFC 3947." RFC 3947 [Kivinen, Swander, Huttunen, and Volpe 2005] specifies the NAT-T negotiation protocol within IKE.

Recall from Chapter 13 that the Vendor ID payload contains a hash of some vendor-defined string.

Once the peers have agreed to negotiate NAT-T, they perform NAT discovery, which determines which, if any, of the peers is behind a NAT. They do this by sending NAT Discovery payloads as part of the phase 1 negotiationspecifically, in the third and fourth messages of Main mode or the second and third messages of Aggressive mode.

The NAT Discovery (NAT-D) payload, shown in Figure 14.7, is a hash of an IP address and port. Each node sends at least two NAT-D payloads: The first is the hash of its peer's address and port, and the second is the address and port from which it is sending. If a node is multihomed and cannot determine which interface it will be using, it sends a NAT-D payload for each of its interfaces, in addition to the one for its peer's IP address and port.

Figure 14.7. The NAT-D Payload

[View full size image]

The hash is calculated as

HASH(CKYi||CKYr||IP||port)

where HASH is the negotiated hash. The payload type for the NAT-D payload is 20.

When a node receives the NAT-D payloads, it checks that

  • The first received NAT-D payload matches one of the NAT-D payloads for its local interfaces

  • One of the other received NAT-D payloads matches the payload for its peer's address, that is, the first NAT-D payload that it sends to its peer

If both of these tests succeed, the addresses have not changed in transit, so there is no NAT between the peers. If the first test fails, this peer is behind a NAT, so it must start sending NAT keep-alives, as discussed in the previous subsection.

Even if the other peer is also behind a NAT, that NAT won't tamper with the destination address. When the first test fails, it means that the destination address has changed and therefore that the receiving node is behind a NAT.

We mentioned previously that IKE and ESP will use port 4500 when NAT-T is in use. The reason for this is that many NATs try to interoperate with IKE by not remapping port 500, even if there are multiple hosts behind the NAT, or by using some other method to demultiplex IKE traffic. By switching to port 4500, IPsec avoids this behavior and ensures that NAT-T can operate as intended.

In Main mode, the initiator changes ports when it sends its Identification payload. Figure 14.8 shows a typical Main mode exchange when NAT-T is in use. The UDP header is included in the flow diagram in order to show which ports IKE is using.

Figure 14.8. Main-Mode Exchange with NAT-T

In the figure, VID is the Vendor ID payload, and NATD is the NAT-D payload.

Notice that in the second message, the responder replies to port X, the remapped port 500 from the initiator (see Exercise 14.7). After the initiator changes ports in the fifth message, the responder begins replying to port Y, the remapped port 4500.

In Aggressive mode, the responder sends its NAT-D payloads in the second message, as shown in Figure 14.9. When the initiator receives this message, it will know whether a NAT is between the peers and, if so, will switch to port 4500. In the third message, the initiator sends its NAT-D payloads, so after receiving this message, the responder can determine whether a NAT is between the peers and also change to port 4500 if there is. Again, note how the responder replies to the remapped ports rather than to port 500 or 4500.

Figure 14.9. Aggressive-Mode Exchange with NAT-T

[View full size image]

RFC 3947 says that the peers may begin their negotiation on port 4500 and thus avoid having to switch ports.

Although not shown in Figure 14.8 or Figure 14.9, there is an additional change to the IKE packets when the peers change to port 4500. Because the encapsulated ESP packets will be carried in UDP datagrams using the same ports as IKE, IPsec must have a way of distinguishing between encapsulated ESP packets and NAT packets. IPsec does this by adding a non-ESP marker of four 0-bytes to IKE packets, as shown in Figure 14.10. Notice that the marker is in the same position as the SPI of an ESP packet.

Figure 14.10. An IKE Packet with NAT-T

[View full size image]

This means that ESP must never send an SPI of 0, but as we saw in Chapter 13, this is illegal anyway.

After one of the exchanges shown in Figure 14.8 or Figure 14.9, IKE has negotiated the use of NAT-T for itself; all future IKE packets will use the new ports and will include the non-ESP marker. The use of NAT-T by ESP is negotiated in the Quick mode exchange by adding two new encapsulation modes to the SA payload: UDP-Encapsulated-Tunnel (3) and UDP-Encapsulated-Transport (4). These two modes replace the normal Tunnel and Transport modes when one or both of the peers is behind a NAT.

Although it provides a port for PAT to remap, UDP encapsulation does not address the problem of TCP/UDP checksums. As mentioned earlier, these checksums include a pseudoheader and therefore depend on the source and destination addresses. NAT itself cannot correct these checksums, because they are encrypted and/or authenticated. Therefore, they must be adjusted after ESP has processed the packet. On the other hand, the receiver may not know the original addresses that were used to calculate the checksum. Therefore, the NAT-T peers must send each other these original addresses.

The peers do this by exchanging their addresses in a NAT-OA packet, shown in Figure 14.11.

Figure 14.11. The NAT-OA Payload

[View full size image]

The NAT-OA payload has a payload type of 21. It is carried in the second and third message of the Quick exchange, as shown in Figure 14.12.

Figure 14.12. The Quick Exchange with NAT-T

[View full size image]

Unsolved Problems

There are interoperability problems between IPsec and NAT that NAT-T doesn't solve. A thorough discussion of these problems and the requirements to solve them are in RFC 3715 [Aboba and Dixon 2004]. We mention two examples from RFC 3948 that illustrate the types of problems that can occur.

For the first example, imagine two mobile hosts in different locations connecting to their home network through a security gateway via a tunnel-mode VPN. Let's suppose that each of the mobile hosts is behind a NAT and that each has an assigned private address of 192.168.0.1, as shown in Figure 14.13.

Figure 14.13. Two Mobile Hosts with the Same Private Address

[View full size image]

When only one of the tunnels is activesay, from host ANAT-T handles everything just as we discussed earlier. The security gateway has an SA that says that traffic to 192.168.0.1 should be protected with ESP using UDP-Encapsulated-Tunnel mode encapsulation and that the traffic should be sent to 1.1.1.1.

Now let's consider what happens if both tunnels are up at the same time. From the point of view of host C or D on the home network, both host A and host B are at 192.168.0.1, with the next hop being the security gateway. The security gateway has two SAs that specify UDP-Encapsulated-Tunnel mode ESP for 192.168.0.1, but they go to different endpoints, and the gateway has no way of determining which SA to use.

The second example shows that transport mode can also be a problem. Suppose that host A and host B are behind the same NAT and that they both want to establish an ESP transport-mode connection to a remote server, host S, and send all their TCP traffic through it. Neither host A nor host B is aware of the other, and from their point of view, they each have a UDP-encapsulated-transport mode SA specifying that all TCP traffic to and from host S should be protected with ESP.

Host S, however, has a problem. From its point of view, both host A and host B have the same addresstheir common NAT's external addressand both SAs say to protect all TCP traffic with ESP. The problem is, host S has no way of knowing which SA, and therefore which keys, to use, because both host A and host B look the same to it. In general, having the same traffic descriptor for multiple hosts behind the same NAT is not possible.


Section 14.7. Summary

14.7. Summary

In this chapter, we took a quick look at the near-term future of IPsec. As we saw, the changes to AH and ESP are minimal, but IKE has been enhanced to make it both simpler and more flexible. IKEv2 is able to negotiate lists of address and port ranges, as well as type/code values for ICMP and IPv6 mobility header types.

The IKEv2 protocol is reliable and uses two message exchanges, making the entire negotiation shorter. IKEv2 can negotiate an IKE SA and the first child SA in only four messages. Because the most common situation requires only these two SAs, we can normally establish an ESP VPN with only four IKE messages.

We also looked at NAT traversal. We saw how NAT-T can solve many, but not all, of the problems caused by the interaction of IPsec and NAT. Part of NAT-T involves NAT discovery, by which the peers determine whether a NAT is between them, so NATT can always be enabled and will adjust to whether a NAT is present when the peers negotiate a new IKE SA.


Exercises

14.1 | Describe a method for checking an extended sequence number when the replay window contains sequence numbers that differ in their upper 32 bits.
14.2 | Sketch an algorithm for decorrelating a policy database that has only two selectors.
14.3 | The longest-match rule for source address, destination address, and SPI requires that the SAD be searched three times. Describe an algorithm for searching the SAD
14.4 | Why is IKEv2 able to create a child SA (with the CREATE_CHILD_SA exchange) in only two messages, whereas the Quick mode exchange from IKEv1 took three messages?
14.5 | Why does it make sense for IKE and the UDP encapsulation of ESP to share ports under NAT-T?
14.6 | Why does the NAT-D hash include the IKE cookies CKYi and CKYr?
14.7 | In Figure 14.8, which peer is behind the NAT? How can we tell?
14.8 | Explain why ESP must never send an SPI of 0 when using NAT-T.


Appendix A. Source Code

    A.1 Introduction

    A.2 Cryptographic Routines

    A.3 Library Code


A.1 Introduction

This appendix contains some miscellaneous source code that was referenced, but did not appear, in the main text. Short descriptions of the few library routines from ETCP used in the text are also included. The source code for these library routines is available on the author's Web site.


A.2 Cryptographic Routines

This section shows implementations of some simple cryptographic algorithms mentioned in Chapter 3. Two implementations of the Extended Euclidean Algorithm, which is used to find inverses in Zp, are also shown.

Be aware that these implementations are intended to illustrate the principles involved and are definitely not meant to be used in real cryptographic software. As we've seen throughout the text, writing robust security software is difficult and requires special diligence to avoid potential exploits. Unfortunately, writing robust security software involves details that obscure the underlying principles the examples are intended to illustrate, so the examples were chosen to favor simplicity over robustness.

A Trivial Cipher

This subsection shows a python implementation (Figure A.1) of the trivial cipher that we saw in Chapter 3. As mentioned there, this cipher is useful only as an example of what not to do.

Figure A.1. An Implementation of the Trivial Cipher

[View full size image]

23 | The tohex function uses the python join/map idiom to return a string of bytes as colon-delimited hex digits.
45 | These lines retrieve the key and message from the command line.
6 | We empty ct, the string that will hold the ciphertext.
912 | We initialize the key stream generator by capturing the length of the key and setting the index into the key to -1.
1318 | The next function returns the next byte of the keythat is, of the key streamby incrementing the index and resetting it to 0 if it exceeds the key length.
19 | This line constructs an instance, ks, of the key stream generator.
2021 | These lines take each byte of the message, exclusive-OR it with the next key stream byte, and append the result to the ciphertext string.
22 | This line prints the encrypted message.

An RC4 Implementation

Figure A.2 shows a python implementation of RC4 written to act as a filter. Notice that it is only barely more complicated than the trivial cipher.

Figure A.2. An Implementation of RC4

[View full size image]

5 | We obtain the key from the command line. Because this application functions as a filter, it will read the plaintext from STDIN and write the ciphertext to STDOUT.
817 | These lines initialize the RC4 state exactly as described in Chapter 3.
1821 | The swap function merely swaps Si and Sj.
2227 | The next function returns the next byte of the key stream. It follows the pseudocode from Chapter 3 very closely.
28 | We instantiate an instance, ks, of the key stream generator.
2930 | These lines continuously read bytes from STDIN, exclusive-OR them with the next byte from the key stream generator, and write the result to STDOUT.

Finding Inverses in Zp

Recall from Chapter 3 that the RSA algorithm requires us to find an inverse for x [image] Zp. That is, given x [image] {0, 1, . . . , p - 1}, where p is prime, find y such that xy mod p = 1. Because x and p are obviously relatively prime for prime p, their greatest common denominator is 1. That is, 1 is the largest integer that divides them both. We can use the Extended Euclidean Algorithm to find m and n such that mx + np = gcd(x, p) = 1. Note that this implies that mx mod p = 1.

We present two implementations of this algorithm: one using the UNIX bc utility and the other using python. Both implementations are based on Algorithm X from Section 4.5.2 of [Knuth 1998].

Our first implementation (Figure A.3) uses bc. Normally, bc is used interactively, but it can also accept input from a script. See Knuth for an explanation of this algorithm and a proof that it is correct.

Figure A.3. A bc-Based Implementation of the Extended Euclidean Algorithm

[View full size image]

Figure A.4 gives a slightly more readable python-based implementation.

Figure A.4. A python-Based Implementation of the Extended Euclidean Algorithm

[View full size image]


A.3 Library Code

Some of the examples in the text used library functions from ETCP. The library code is publicly available, so rather than complete listings, short descriptions of the functions are given.

The error Function

The first function, error, is a generalized diagnostic routine. It can report errors or diagnostics and continue processing, or it can report a fatal error and terminate the process. The function writes its output to STDERR. The error prototype is:

[View full size image]

If status is 0, error will output the diagnostic and return. When status is nonzero, error will output the diagnostic and exit with a status of status. If err is nonzero, error treats it as an errno value and will append the error string associated with that value by calling strerror. The format parameter is a standard printf formatting string that error uses along with any following arguments to format the diagnostic.

The tcp_server and tcp_client Functions

The tcp_server and tcp_client functions establish a TCP connection. In the case of tcp_server, the function accepts a host and a port and returns a listening socket. In the case of tcp_client, the function also accepts a host and a port, and returns a socket connected with the specified peer.

The prototype for tcp_server is:

[View full size image]

The host parameter points to a string that tells tcp_server which interface it should listen on. The string can be an ASCII IP address, a host name, or NULL. If it is NULL, tcp_server will listen on all the host's interfaces. Similarly, the port parameter points to a string that tells tcp_server which port to listen on. It can be either an ASCII port number or a symbolic service name. The function returns a socket that is listening for connections on the specified interface and port. The caller is expected to use this socket as an input to the accept function.

The prototype for tcp_client is:

[View full size image]

The host parameter points to a string that contains the name or address of the host to connect to. It can be either an ASCII IP address or the name of the host. The port parameter points to a string that contains the port number or name that tcp_client should connect to. It can be either an ASCII port number or a symbolic service name. The function returns a connected socket or terminates.


Appendix B. Miscellaneous Software

    B.1 Netcat

    B.2 tcpdump and Other Packet Sniffers

    B.3 ssldump

    B.4 PPP


B.1 Netcat

Some of the examples in the text use the netcat program (nc) as a client application. Netcat describes itself as a "TCP/IP Swiss army knife" because it is designed to handle a variety of common chores.

Its name comes from the fact that it tries to act as much as possible like the UNIX cat utility but over a network. Thus, its basic purpose is to read and write data across a network using TCP or UDP. Although used in this text primarily as a telnet-like utility to connect to servers on the same or other machines, it is much more flexible. We can gain an appreciation for some of that flexibility by asking netcat to print its help information, as shown in Figure B.1.

Figure B.1. Netcat Command Line Options

[View full width]
nc -h
[v1.10]
connect to somewhere:    nc [-options] hostname
   port[s] [ports] ...
listen for inbound:      nc -l -p port [-options]
   [hostname] [port]
options:
    -4               Use IPv4 (default)
    -6               Use IPv6
    -A algorithm     cast256, mars, saferp,
   twofish, or rijndael
    -k password      AES encrypt and ascii armor
   session
    -b               allow broadcasts
    -g gateway       source-routing hop point[s],
   up to 8
    -G num           source-routing pointer: 4, 8,
   12, ...
    -h               this cruft
    -i secs          delay interval for lines sent
  , ports scanned
    -l               listen mode, for inbound connects
    -n               numeric-only IP addresses, no DNS
    -o file          hex dump of traffic
    -p port          local port number
    -r               randomize local and remote ports
    -q secs          quit after EOF on stdin and
   delay of secs
    -s addr          local source address
    -t               answer TELNET negotiation
    -u               UDP mode
    -v               verbose [use twice to be more
   verbose]
    -w secs          timeout for connects and
   final net reads
    -z               zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi
   [inclusive]

As an example, we use netcat to listen on a port and send a file of data to the first user that connects:

nc -l -p 6666 -q 3 < some_file

The -q 3 tells netcat to terminate 3 seconds after it reads an EOF on STDIN. The 3-second delay is to allow time for the last buffer of data to be sent.

More generally, we can set up pipelines on each side of the connection to process data before and after it is sent. Here is an example, adapted from the netcat documentation, that transfers a directory from one machine to another, compressing it for transmission. On the receiving machine, we set up a pipeline that listens for the connection from the sending machine, receives the data, decompresses it, and stores it in a parallel directory:

nc -l -p 6666 | gzip -dc | tar -xpf -

On the sending side, we execute the pipeline:

tar -cpf - directory_to_send | gzip -c | nc -w 3 remote_host 6666

The -w 3 allows time for the data to drain from the kernel buffers before terminating the connection.

This method works whether or not the particular version of tar that we're using supports compression. More generally, we could pre- and postprocess the data in any way that we desire.

The best discussion of netcat's capabilities and how to use them is in the README file that accompanies the distribution. Netcat can be obtained from the Freshmeat archive at <http://freshmeat.net/redir/netcat/7041/url_tgz/nc110.tgz>.


B.2 tcpdump and Other Packet Sniffers

Throughout the text, we use tcpdump to watch the on-the-wire behavior of the tunnels and VPNs that we study. It's worth taking a moment to specify how we use tcpdump to capture this data and how we reformat the data for better presentation in the text.

To show the effect of the various tcpdump options, let's ping from linux to bsd and capture the results. If we run tcpdump without any options, we get

16:17:37.684842 IP linux.jcs.local > bsd.jcs.local: icmp 64: echo request seq 1
16:17:37.684948 IP bsd.jcs.local > linux.jcs.local: icmp 64: echo reply seq 1

This output is set in smaller type so that it will fit on one line and appear exactly as it does on a terminal screen.

Often, it is more useful to see the IP addresses than it is the host names. Indeed, that is the way most of the captures in the text are run. To do this, we use the -n option with tcpdump. That gives us the result

16:17:37.684842 IP 172.30.0.4 > 172.30.0.1: icmp 64: echo request seq 1
16:17:37.684948 IP 172.30.0.1 > 172.30.0.4: icmp 64: echo reply seq 1

If we want to see exactly what's in the packet instead of relying on tcpdump to decode it for us, we can specify the -x option, which gives us a hex dump of the packet, or the -X option, which gives us a hex and ASCII dump. Be aware that tcpdump captures only the first few bytes by default, so if we want to examine the entire packet contents, we should tell tcpdump to capture as much data as we're interested in.

The amount of data that tcpdump captures by default depends on the platform it's running on. It's usually 68 bytes, but some packet-capture interfaces support other lengths.

We can set the amount of data to capture with the -s option.

Almost all the examples in the text invoke tcpdump as

tcpdump -nXs 1500 filter_expression

where filter_expression specifies which packets tcpdump should capture. If we don't specify a filter, tcpdump will capture all packets. If we were interested only in packets from linux to bsd, we would specify a filter of src linux and dst bsd. The tcpdump filter language is surprisingly rich and therefore complicated. It is described in detail in the tcpdump man page.

For our ping example, we are interested only in ICMP packets, so we can specify a filter of icmp and capture only ICMP packets. We capture the results of our ping with

tcpdump -nXs 1500 icmp

and get

16:17:37.684842 IP 172.30.0.4 > 172.30.0.1: icmp 64: echo request seq 1
    0x0000: 4500 0054 0000 4000 4001 e267 ac1e 0004   E..T..@.@..g....
    0x0010: ac1e 0001 0800 aab1 0e0b 0001 e189 5942   ..............YB
    0x0020: 0f73 0a00 0809 0a0b 0c0d 0e0f 1011 1213   .s..............
    0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223   .............!"#
    0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233   $%&'()*+,-./0123
    0x0050: 3435 3637 4567
16:17:37.684948 IP 172.30.0.1 > 172.30.0.4: icmp 64: echo reply seq 1
    0x0000: 4500 0054 8c8b 4000 4001 55dc ac1e 0001   E..T..@.@.U.....
    0x0010: ac1e 0004 0000 b2b1 0e0b 0001 e189 5942   ..............YB
    0x0020: 0f73 0a00 0809 0a0b 0c0d 0e0f 1011 1213   .s..............
    0x0030: 1415 1617 1819 1a1b 1c1d 1e1f 2021 2223   .............!"#
    0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233   $%&'()*+,-./0123
    0x0050: 3435 3637                                 4567

Notice that tcpdump does not number the lines the way we do in the text. Instead, it gives the offsetfrom the start of the packetof the first byte of each line. Such output is usually the most useful when debugging a VPN by looking at its behavior on the wire.

When using tcpdump to diagnose VPN and tunnel behavior, it is imperative to understand how and where it works. Figure B.2 shows a typical invocation of tcpdump.

Figure B.2. Capturing Packets with tcpdump

Notice that tcpdump uses the pcap library (libpcap) to filter and capture the packets. The pcap library provides general packet capture and filtering facilities and can be used by other programs that need to examine packets as seen by the interface layer. We'll see an example of this when we discuss ssldump.

Figure B.2 shows tcpdump using the Berkeley Packet Filter (BPF) mechanism to capture the packets. BPF is the kernel interface to the pcap library used in BSD-derived UNIX systems. Other operating systems have other kernel interfaces, but the concepts are the same.

The important thing to note in Figure B.2 is where the packet is captured. Pcap grabs a copy just after it's received from the network hardware (NIC) or just before it's sent to the NIC. Thus, we will see the packet before any processing by the TCP/IP stackin the case of inbound packetsor after all such processing is completein the case of outbound packets.

We are not counting the I/O processing that the interface layer uses to read from or write to the NIC, of course.

This can be a little confusing when pseudointerfaces, such as the tun or tun/tap interfaces, come into play, because the packets may have been partially processed before they get to such interfaces. If we remember that the tun interface, say, looks like a normal NIC interface driver to the rest of the stack, we can usually understand what tcpdump is showing us when we capture data at such interfaces.

Although we use exclusively tcpdump in the text, it's not the only possibility. Some UNIX systems have their own packet sniffers. Solaris has snoop, and IBM AIX has iptrace, for example. Nonetheless, tcpdump runs on Solaris, AIX, Windows, and virtually all other UNIX systems. Because it is generally available on all systems, it pays to be familiar with it and its operation.

For those who prefer a graphical user interface, the ethereal sniffer is an ideal solution. It too runs on virtually all UNIX and Windows systems. The ethereal sniffer can read packet captures from several other sniffers, including tcpdump, etherpeek (Windows), snoop (Solaris), LANalyzer (Novell), iptrace (AIX), nettl (HP-UX), and other, less common formats as well.

Tip 34 of ETCP covers the use of tcpdump in greater detail. The latest version of tcpdump is available from <http://www.tcpdump.org>. The ethereal sniffer is available from <http://www.ethereal.com>.


B.3 ssldump

Chapter 6 makes extensive use of Eric Rescorla's ssldump program. It's similar in concept and operation to tcpdump but is specialized to decode SSL packets.

One of ssldump's most useful features is its ability to decrypt the SSL payloads when we have access to the SSL key file. This capability is useful only when we are working with our own SSL servers, of course, but that is usually exactly when we need it.

Architecturally, ssldump is very similar to tcpdump, using the pcap library to capture packets from the interface, filtering them according to the filter expression, and using the OpenSSL library to decode them. See Chapter 6 for examples of the SSL output.

In our examples, we use three of ssldump's options extensively.

-A |  | Print all fields in the SSL record instead of just the most interesting ones.
-d |  | Display application data. This is also useful for seeing TCP traffic before the SSL session initiation.
-k | file | Specify the location of the key file that can be used to decrypt the SSL payload data.

Here is a fragment of an ssldump output from Chapter 6:

2 1 0.0011 (0.0011) C>SV3.0(79) Handshake
     ClientHello
       Version 3.0
       random[32]=
         3e 5e 6f db 15 04 57 00 03 5a a8 ae 30 89 8b 6c
         e9 21 e6 0e 08 23 18 cc 5a 9c 4e bb 20 36 aa f9
       resume [32]=
         14 17 3a 80 5e 1d 50 9f 46 1c 38 12 2f e6 d8 3d
         b6 6c 18 59 8b 00 f4 3d a1 1c 2f 22 72 80 37 50
       cipher suites
       SSL_RSA_WITH_3DES_EDE_CBC_SHA
       SSL_RSA_WITH_IDEA_CBC_SHA
       compression methods
                 NULL

The leading two numbers on the first line provide the connection and record numbers. Thus, this is SSL record 1 from connection 2. The next two numbers are the time since the beginning of the connection and the time since the last record. In this case, they are the same because this is the first record in the connection.

The next field tells us that this packet is from the client to the server (C>S), that we are using SSL version 3.0, and that the record is 79 bytes long. The last field indicates the record type (see Figure 6.4). In this case, it's a Handshake message. Once the session enters encrypted modethat is, after the CHANGE_CIPHER_SPEC messagethis first line is all that will be visible unless we have the server key.

The rest of the output is a decode of the fields within the record. We see that this is a ClientHello message for a session resumption and that two cipher suites are being offered by the client.

It is sometimes convenient to be able to see the application data, and for this, ssldump offers the -x and -X options, just as tcpdump does. Here's an example, again from Chapter 6, of ssldump's output of application data:

1 40 72.1196 (11.9504) S>CV3.0(112) application_data
  ---------------------------------------------------------------
  7e 21 45 00 00 54 72 7b 40 00 40 01 82 80 0a 00  ~!E..Tr{@.@.....
  00 04 c0 a8 7b 01 08 00 56 21 63 11 01 00 3c 5a  ....{...V!c...<Z
  90 3e 7a 31 0c 00 08 09 0a 0b 0c 0d 0e 0f 10 11  .>z1............
  12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21  .............. !
  22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31  "#$%&'()*+,-./01
  32 33 34 35 36 37 92 51 7e                       234567.Q~
  ---------------------------------------------------------------

Notice that this is data from the server to the client and that the record type is APPLICATION_DATA.

Further information about ssldump and the SSL/TLS protocol is available in Rescorla's excellent text SSL and TLS [Rescorla 2001]. The ssldump source code distribution and information about the book is available from Rescorla's Web site at <http://www.rtfm.com/ssldump/ssldump-0.9b3.tar.gz>.


B.4 PPP

Most PPP implementations fall into one of two categories: They are implemented either in the kernel just below the IP layer in the TCP/IP stack or in user space and use a tunnel driver, such as the FreeBSD tun driver, to communicate with the TCP/IP stack. Our test systems include examples of both methods. The Linux and Solaris operating systems use an in-kernel PPP implementation. If we think of PPP as another layer in the TCP/IP stack, then the top of the PPP layer talks to the IP layer, and the bottom of the PPP layer talks, by default, to the serial port device driver.

Actually, Linux uses a hybrid method, in which the encapsulation is done in the kernel, but the LCP/NCP processing is done by the user-space pppd program. PPP packets containing IP datagrams are handled in the kernel and do not go through pppd.

It is often convenient to have the bottom of the PPP layer communicate with the STDIN and STDOUT interfaces of a user-space process. This is usually accomplished by having PPP connect to a pseudo-tty device [Stevens 1992] rather than an actual serial device. Because we are interested primarily in using PPP to form tunnels, this is the mode that we usually use, and we see examples of this use in the text.

The help screen from pppd, shown in Figure B.3, lists the most important options and gives us an idea of how to use it.

Figure B.3. Common pppd Options

[View full width]
pppd -h
pppd version 2.4.1
Usage: pppd [ options ], where options are:
    <device>      Communicate over the named device
    <speed>       Set the baud rate to <speed>
    <loc>:<rem>   Set the local and/or remote
   interface IP
                     addresses.  Either one may be
   omitted.
    asyncmap <n>  Set the desired async map to hex <n>
    auth          Require authentication from peer
    connect <p>   Invoke shell command <p> to set
   up the serial line
    crtscts       Use hardware RTS/CTS flow control
    defaultroute  Add default route through interface
    file <f>      Take options from file <f>
    modem         Use modem control lines
    mru <n>       Set MRU value to <n> for negotiation
See pppd(8) for more options.

In addition to the options listed in the help screen, we use the notty option, which tells pppd to open a pseudo-tty so that we can intercept the PPP frames and encapsulate them in our tunnels. These are only a few of the options; the typeset man page for pppd is more than 20 pages.

Several additional scripts can help control the PPP link. After authentication succeeds, pppd will check for the existence of the /etc/ppp/auth-up script. If it exists, pppd will execute it. If the auth-up script is executed, /etc/ppp/auth-down will be executed, if it exists, when the link is torn down. Similar scripts are run when an NCP starts and stops. For example, /etc/ppp/ip-up is run when the link is ready to send or receive IP datagrams, and /etc/ppp/ip-down is run when the link is no longer able to send or receive IP datagrams.

An excellent discussion of the internals of pppd and how the kernel and user-space portions of the PPP implementation communicate is given in PPP Design and Debugging [Carlson 2000]. As mentioned in Chapter 2, Carlson's book is an excellent reference for the specifics of PPP and explains the functioning of its state machines in detail.

FreeBSD's PPP implementation is an example of the second method, in which all the PPP processing takes place in a user-space program. In FreeBSD, this program is called ppp. Figure B.4 shows how ppp communicates with the TCP/IP stack. Note the similarity to our gtunnel implementation. The figure shows ppp communicating with a serial driver for its external I/O, but we most often set it to communicate either through the TCP/IP stackwhen we encapsulate PPP frames in TCP segments or UDP datagramsor through its STDIN and STDOUT, as we do in Chapter 6, where we want it to communicate through another program.

Figure B.4. The FreeBSD PPP Architecture

Because ppp is so flexible and has so many optionsthe typeset man page is almost 50 pagesalmost all the configuration is done by a configuration file. The command line interface merely selects a mode, a "system," and a few options, as we see from the help screen:

bsd# ppp -h
usage: ppp [-auto | -foreground | -background | -direct |
-dedicated | -ddial | -interactive] [-nat] [-quiet]
[-unit N] [system ...]

The first set of choices is the mode, which selects the manner in which ppp will operate.

The modes are:

auto | ppp opens the connection to the TCP/IP stack and becomes a daemon but takes no further action until it sees an IP packet, at which point it will attempt to contact the remote system.
foreground | ppp attempts to establish a connection with the remote system immediately but does not become a daemon.
background | ppp attempts to establish a connection with the remote system immediately. If ppp succeeds, it becomes a daemon; otherwise, it exits with a failure status.
direct | This mode causes ppp to listen for connections rather than trying to establish a connection to the remote system.
dedicated | This mode indicates that ppp has a dedicated connection to the remote system, and no chat script is necessary to establish communications.
ddial | This mode is like the auto mode, but will try to reestablish the connection if it is dropped.
interactive | This mode allows a user to control its operation interactively.

The -nat option enables ppp's internal NAT. The -quiet option inhibits ppp's output to the console when it starts. The -unit N option allows the user to specify which tun interface ppp should use. Without this option, ppp will use the first available tun device.

The configuration of PPP connections is specified in the /etc/ppp/ppp.conf file. The ppp.conf file can contain configurations for several PPP connections. These configurations are separated into named sections in the file, and it is one or more of these that the user specifies for "system . . ." when calling ppp.

Chapter 6 has an example of a ppp.conf file when ppp is used in an SSL tunnel. Figure B.5 is another example, showing the configuration for a normal ppp session over a serial line.

Figure B.5. A Typical ppp.conf File

[View full size image]

Most of the options in the configuration file are self-explanatory. Because the options are discussed in detail in the ppp man page and because there are so many of them, we won't discuss them further.

In addition to reading the ppp.conf file, ppp checks for the existence of a /etc/ppp/ppp.linkup file when a link is established. If the file exists, its contents are executed. It can set ppp parameters or run arbitrary scripts. A common use is to set a route, as we do in Chapter 6. Similarly, the /etc/ppp/ppp.linkdown script is checked when the link is torn down.


Bibliography

Aboba, B., Blunk, L. J., Vollbrecht, J. R., Carlson, J., and Levkowetz, H. 2004. "Extensible Authentication Protocol (EAP)," RFC 3748 (June).

Aboba, B. and Dixon, W. 2004. "IPsec-NAT Compatibility Requirements," RFC 3715 (Mar.).

Agarwal, P. and Akyol, B. 2003. "Time to Live (TTL) Processing in Multi-Protocol Label Switching (MPLS)," RFC 3443 (Jan.).

Alvestrand, H. T. 2001. "Tags for the Identification of Languages," RFC 3066 (Jan.).

Anderson, R. 1993. "The Classification of Hash Functions," Proceedings of the Fourth IMA Conference on Cryptography and Coding, pp. 8393. http://www.ftp.cl.cam.ac.uk/ftp/users/rja14/hash.ps.Z

Andersson, L., Doolan, P., Feldman, N., Fredette, A., and Thomas, B. 2001. "LDP Specification," RFC 3036 (Jan.).

Barrett, D. J. and Silverman, R. E. 2002. SSH, The Secure Shell: The Definitive Guide. O'Reilly & Associates, Sebastopol, Calf.

Baugher, M., Weis, B., Hardjono, T., and Harney, H. 2003. "The Group Domain of Interpretation," RFC 3547 (July).

Bellare, M., Canetti, R., and Krawczyk, H. 1996. "Keyed Hash Functions and Message Authentication," Advances in CryptologyCRYPTO '96, Lecture Notes in Computer Science, no. 1109, pp. 115, Springer-Verlag. http://www.research.ibm.com/security/keyed-md5.html

Bellare, M., Kohno, T., and Namprempre, C. 2002. "Authenticated Encryption in SSH: Provably Fixing the SSH Binary Packet Protocol," Proceedings of the 9th ACM Conference on Computer and Communications Security, pp. 111 (Nov.). http://www.cs.ucsd.edu/users/tkohno/papers/SSH/

Bellovin, S. M. 1996. "Problem Areas for the IP Security Protocols," Proceedings of the 6th USENIX Security Symposium, pp. 116 (July). http://www.research.att.com/~smb/papers/badesp.ps

Bellovin, S. M. 1997. "Probable Plaintext Cryptanalysis of the IP Security Protocols," Proceedings of the Symposium on Network and Distributed System Security, pp. 155160 (Feb.). http://www.research.att.com/~smb/papers/probtxt.ps

Bleichenbacher, D. 1998. "Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS#1," Advances in Cryptology-CRYPTO '98, Lecture Notes in Computer Science, no. 1462, pp. 112, Springer-Verlag. http://www.bell-labs.com/user/bleichen/papers/pkcs.ps.gz

Bleichenbacher, D., Kalisky, B., and Staddon, J. 1998. "Recent Results on PKCS #1: RSA Encryption Standard," Bulletin 7, RSA Laboratories (June). ftp://ftp.rsasecurity.com/pub/pdfs/bulletn7.pdf

Braden, R. T., Borman, D., and Partridge, C. 1988. "Computing the Internet Checksum," RFC 1071 (Sept.).

Brumley, D. and Boneh, D. 2003. "Remote Timing Attacks Are Practical," Proceedings of the 12th USENIX Security Symposium, pp. 114 (Aug.). http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html

Canvel, B., Hiltgen, A., Vaudenay, S., and Vuagnoux, M. 2003. "Password Interception in a SSL/TLS Channel," Advances in Cryptology-CRYPTO '03, Lecture Notes in Computer Science, no. 2729, pp. 583599, Springer-Verlag. http://lasecwww.epfl.ch/pub/lasec/doc/CHVV03.ps

Carlson, J. 2000. PPP Design, Implementation, and Debugging, Second Edition. Addison-Wesley, Boston, Mass.

Comer, D. E. 2000. Internetworking with TCP/IP Volume I: Principles, Protocols, and Architecture, Fourth Edition. Prentice Hall, Englewood Cliffs, N.J.

Dai, W. 2002. "An Attack Against SSH2 Protocol," Message-ID <20020206134116.A24813@eskimo.com>, IETF Secsh Working Group Email List (Feb.). ftp://ftp.ietf.org/ietf-mail-archive/secsh/2002-02.mail

Davis, C. R. 2001. IPSec: Securing VPNs. McGraw-Hill, Berkeley, Calif.

Dawson, E. and Nielsen, L. 1996. "Automated Cryptanalysis of XOR Plaintext Strings," Cryptologia, vol. 20, no. 2, pp. 165181 (Apr.).

Deering, S. E. and Hinden, R. M. 1998. "Internet Protocol, Version 6 (IPv6) Specification," RFC 2460 (Dec.).

Dierks, T. and Allen, C. 1999. "The TLS Protocol: Version 1.0," RFC 2246 (Jan.).

Diffie, W. and Hellman, M. 1976. "New Directions in Cryptography," IEEE Transactions on Information Theory, vol. IT-22, no. 6, pp. 644654 (Nov.).

Dijkstra, E. W. 1959. "A Note on Two Problems in Connection with Graphs," Numerische Mathematic, vol. 1, pp. 269271.

Dommety, G. 2000. "Key and Sequence Number Extensions to GRE," RFC 2890 (Sept.).

Doraswamy, N. and Harkins, D. 1999. IPSec, The New Security Standard of the Internet, Intranets, and Virtual Private Networks. Prentice Hall PTR, Upper Saddle River, N.J.

Dreyfus, S. 1997. Underground: Tales of Hacking, Madness, and Obsession on the Electronic Frontier. Mandarin, Kew, Australia. http://onlinebooks.library.upenn.edu/webbin/gutbook/lookup?num=4686

Dworkin, M. 2001. "Recommendation for Block Cipher Modes of OperationMethods and Techniques," NIST Special Publication 800-38a, National Institute of Standards and Technology (Dec.). http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf

Eastlake, D. E., 3rd, Crocker, S. D., and Schiller, J. I. 1994. "Randomness Recommendations for Security," RFC 1750 (Dec.).

Egevang, K. B. and Francis, P. 1994. "The IP Network Address Translator (NAT)," RFC 1631 (May).

Electronic Frontier Foundation 1998. Cracking DES. O'Reilly & Associates, Sebastopol, Calif.

ElGamal, T. 1985. "A Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms," IEEE Transactions on Information Theory, vol. IT-31, no. 4, pp. 469472 (July).

Etienne, J. 2001. "Security Analysis of VTun," white paper (Dec.). http://www.netsys.com/library/papers/vtun_secu.pdf

Farinacci, D., Li, T., Hanks, S., Meyer, D., and Traina, P. 2000. "Generic Routing Encapsulation (GRE)," RFC 2784 (Mar.).

Faucheur, F. L., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and Heinanen, J. 2002. "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services," RFC 3270 (May).

Ferguson, N. and Schneier, B. 1999. "A Cryptographic Evaluation of IPsec," white paper, Counterpane Internet Security. http://www.counterpane.com/ipsec.pdf

Ferguson, N. and Schneier, B. 2003. Practical Cryptography. John Wiley & Sons, N.Y.

Fluhrer, S., Mantin, I., and Shamir, A. 2001. "Weaknesses in the Key Scheduling Algorithm of RC4," Lecture Notes in Computer Science, vol. 2259, pp. 124, Springer-Verlag. http://www.crypto.com/papers/others/rc4_ksaproc.ps

Ford, L. R. and Fulkerson, D. R. 1962. Flows in Networks. Princeton University Press, Princeton, N.J.

Freier, A. O., Karlton, P., and Kocker, P. C. 1996. "The SSL Protocol: Version 3.0," RFC draftfreier-ssl-version3-02 (Nov.). http://wp.netscape.com/eng/ssl3/draft302.txt

Fuller, V., Li, T., Yu, J., and Varadhan, K. 1993. "Classless Inter-Domain Routing (CIDR): An Address Assignment," RFC 1519 (Sept.).

Futoransky, A., Kargieman, E., and Pacetti, A. M. 1998. "An Attack on CRC-32 Integrity Checks of Encrypted Channels Using CBC and CFB Modes," white paper, Core Security Technologies (Oct.). http://tinyurl.com/27ddk

Garman, J. 2003. Kerberos: The Definitive Guide. O'Reilly & Associates, Sebastopol, Calf.

Goldberg, I. and Wagner, D. 1996. "Randomness and the Netscape Browser," Dr. Dobb's Journal (Jan.). http://www.ddj.com/documents/s=965/ddj9601h/9601h.htm

Gutmann, P. 2000. "X.509 Style Guide," white paper (Oct.). http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

Gutmann, P. 2003a. "Everything You Never Wanted to Know About PKI but Have Been Forced to Find Out," white paper. http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf

Gutmann, P. 2003b. "Linux's Answer to MS-PPTP," white paper (Sept.). http://www.cs.auckland.ac.nz/~pgut001/pubs/linux_vpn.txt

Gutmann, P. 2005. Private communication.

Haller, N. M. 1994. "The S/KEY One-time Password System," Proceedings of the ISOC Symposium on Network and Distributed System Security (Feb.), San Diego, Calif. http://tinyurl.com/38vur

Haller, N. M. 1995. "The S/KEY One-Time Password System," RFC 1760 (Feb.).

Hamzeh, K., Pall, G. S., Verthein, W., Taarud, J., Little, W. A., and Zorn, G. 1999. "Point-to-Point Tunneling Protocol (PPTP)," RFC 2637 (July).

Hanks, S., Li, T., Farinacci, D., and Traina, P. 1994. "Generic Routing Encapsulation (GRE)," RFC 1701 (Oct.).

Harkins, D. and Carrel, D. 1998. "The Internet Key Exchange (IKE)," RFC 2409 (Nov.).

Hedrick, C. 1988. "Routing Information Protocol," RFC 1058 (June).

Herzog, J. 1999. "A Suggested Improvement to SSHv2," WN99B000041, The MITRE Corporation. http://www.mitre.org/work/tech_papers/tech_papers_00/herzog_improvement/herzog_improvement.pdf

Hickman, K. E.B. 1995. "The SSL Protocol," Unpublished RFC draft (Feb.). http://wp.netscape.com/eng/security/SSL_2.html

Hinden, R. and Deering, S. 2003. "Internet Protocol Version 6 (IPv6) Addressing Architecture," RFC 3513 (Apr.).

Hinden, R. M. 1993. "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)," RFC 1517 (Sept.).

Hollenbeck, S. 2004. "Transport Layer Security Protocol Compression Methods," RFC 3749 (May).

Housley, R., Polk, T., Ford, W., and Solo, D. 2002. "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile," RFC 3280 (Apr.).

Huitema, C. 2000. Routing in the Internet, Second Edition. Prentice Hall, Upper Saddle River, N.J.

Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and Stenberg, M. 2005. "UDP Encapsulation of IPsec Packets," RFC 3948 (Jan.).

International Standards Organization 1984. "OSIBasic Reference Model," ISO 7498, International Standards Organization, Geneva.

International Telecommunication Union 2000. Recommendation X.509-The Directory: Public-key and Attribute Certificate Frameworks. International Telecommunication Union, Geneva http://www.itu.int/rec/recommendation.asp?type=items&lang=e&parent=TREC-X.509-200003-I

Ioannidis, J. and Blaze, M. 1993a. "Architecture and Implementation of Network-Layer Security under Unix," Proceedings of the USENIX Security Workshop (Oct.). http://www.crypto.com/papers/swipeusenix.ps

Ioannidis, J. and Blaze, M. 1993b. "The swIPe IP Security Protocol," Internet Draft (Dec.). http://www.crypto.com/papers/swipe.id

ISO 1992. "Network Layer Security Protocol," ISO/IEC DIS-11577, International Standards Organization (Nov.).

Jacobson, V. 1990. "Compressing TCP/IP Headers for Low-Speed Serial Links," RFC 1144 (Feb.).

Johnson, D. B., Perkins, C. E., and Arkko, J. 2004. "Mobility Support for IPv6," RFC 3775 (June).

Kaliski, B. and Robshaw, M. 1995. "The Secure Use of RSA," CryptoBytes, vol. 1, no. 3, pp. 713 (Autumn), RSA Laboratories. ftp://ftp.rsasecurity.com/pub/cryptobytes/crypto1n3.pdf

Kaufman, C., Perlman, R., and Speciner, M. 2002. Network Security: Private Communications in a Public World, Second Edition. Prentice Hall PTR, Upper Saddle River, N.J.

Kent, S. and Atkinson, R. 1998a. "IP Authentication Header," RFC 2402 (Nov.).

Kent, S. and Atkinson, R. 1998b. "IP Encapsulating Security Payload," RFC 2406 (Nov.).

Kent, S. and Atkinson, R. 1998c. "Security Architecture for the Internet Protocol," RFC 2401 (Nov.).

Kivinen, T., Swander, B., Huttunen, A., and Volpe, V. 2005. "Negotiation of NAT-Traversal in the IKE," RFC 3947 (Jan.).

Klima, V. 2005. "Finding MD5 Collisions on a Notebook Using Multi-Message Modifications," Preprint (Mar.). http://eprint.iacr.org/2005/102

Knuth, D. E. 1998. The Art of Computer Programming, Volume 2, Seminumerical Algorithms, Third Edition. Addison-Wesley, Reading, Mass.

Kolesnikov, O. and Hatch, B. 2002. Building Linux Virtual Private Networks (VPNs). New Riders Publishing, Indianapolis, Ind.

Krawczyk, H. 1996. "SKEME: A Versatile Secure Key Exchange Mechanism for Internet," in Proceedings of the 1996 Symposium on Network and Distributed System Security (SNDSS '96), pp. 114. IEEE Computer Society http://www.research.ibm.com/security/skeme.ps

Krawczyk, H. 2001. "The Order of Encryption and Authentication for Protecting Communications (Or: How Secure Is SSL?)," Proceedings on Crypto '01, Lecture Notes in Computer Science, no. 2139, pp. 310331 (Aug.), Springer-Verlag. http://eprint.iacr.org/2001/045.ps

Krawczyk, H., Bellare, M., and Canetti, R. 1997. "HMAC: Keyed-Hashing for Message Authentication," RFC 2104 (Feb.).

Lenstra, A., Wang, X., and Wegner, B. de 2005. "Colliding X.509 Certificates," Preprint (Mar.). http://eprint.iacr.org/2005/067

Lipmaa, H., Rogaway, P., and Wagner, D. 2000. "Comments to NIST Concerning AES Modes of Operations: CTR-Mode Encryption," First NIST Workshop on Modes of Operation for Symmetric Key Block Ciphers (Oct.). http://csrc.nist.gov/CryptoToolkit/modes/workshop1/papers/lipmaactr.pdf

Madson, C. and Doraswamy, N. 1998. "The ESP DES-CBC Cipher Algoritm with Explicit IV," RFC 2405 (Nov.).

Madson, C. and Glenn, R. 1998a. "The Use of HMAC-MD5-96 Within ESP and AH," RFC 2403 (Nov.).

Madson, C. and Glenn, R. 1998b. "The Use of HMAC-SHA-1-96 Within ESP and AH," RFC 2404 (Nov.).

Malkin, G. S. 1994. "RIP Version 2: Carrying Additional Information," RFC 1723 (Nov.).

Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and Wheeler, R. 1999. "A Method for Transmitting PPP over Ethernet (PPPoE)," RFC 2516 (Feb.).

Maughan, D., Schertler, M., Schneider, M., and Turner, J. 1998. "Internet Security Association and Key Management Protocol (ISAKMP)," RFC 2408 (Nov.).

Menezes, A. J., Oorschot, P. C. van, and Vanstone, S. A. 1996. Handbook of Applied Cryptography. CRC Press, Boca Raton, Fla.

Merkle, R. 1978. "Secure Communications Over Insecure Channels," Communications of the ACM, vol. 21, no. 4, pp. 294299.

Messmer, E. 2000. "Win 2000 VPN Technology Causes Stir," Network World (Jan. 10). http://www.nwfusion.com/news/2000/0110vpn.html

Mister, S. and Tavares, S. E. 1999. "Cryptanalysis of RC4-like Ciphers," Lecture Notes in Computer Science, vol. 1556, pp. 131143, Springer-Verlag. http://www.cs.columbia.edu/~dcook/candexam/Y_23_rc4_cryptana.pdf

Mogul, J. and Deering, S. 1990. "Path MTU Discovery," RFC 1191 (Nov.).

Mogul, J. and Postel, J. B. 1985. "Internet Standard Subnetting Procedure," RFC 950 (Aug.).

Moy, J. T. 1998a. "OSPF Version 2," RFC 2328 (Apr.).

Moy, J. T. 1998b. OSPF: Anatomy of an Internet Routing Protocol. Addison-Wesley, Reading, Mass.

Narten, T., Nordmark, E., and Simpson, W. A. 1998. "Neighbor Discovery for IP Version 6 (IPv6)," RFC 2461 (Dec.).

NIST 1990. "Secure Data Network System (SDNS) Network, Transport, and Message Security Protocols," NISTIR 90-4250, National Institute of Standards and Technology (Feb.).

NIST 1999. "Data Encryption Standard (DES)," FIPS PUB 46-3, National Institutes of Standards and Technology (Oct.). http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf

NIST 2001. "Digital Signature Standard (DSS)," FIPS PUB 186-2 (+Change Notice), National Institute of Standards and Technology (Oct.). http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf

NIST 2002a. "Advanced Encryption Standard (AES)," FIPS PUB 197, National Institute of Standards and Technology (Nov.). http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf

NIST 2002b. "Secure Hash Standard," FIPS PUB 180-2, National Institute of Standards and Technology (Aug.). http://csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf

Orman, H. K. 1998. "The OAKLEY Key Determination Protocol," RFC 2412 (Nov.).

Pall, G. S. and Zorn, G. 2001. "Microsoft Point-to-Point Encryption (MPPE) Protocol," RFC 2118 (Mar.).

Patel, B. V., Aboba, B., Dixon, W., Zorn, G., and Booth, S. 2001. "Securing L2TP using IPsec," RFC 3193 (Nov.).

Pepelnjak, I. and Guichard, J. 2001. MPLS and VPN Architectures. Cisco Press, Indianapolis, Ind.

Pereira, R. and Adams, R. 1998. "The ESP CBC-Mode Cipher Algorithms," RFC 2451 (Nov.).

Perkins, C. 1996. "IP Encapsulation within IP," RFC 2003 (Oct.).

Perlman, R. 2000. Interconnecions: Bridges, Routers, Switches, and Internetworking Protocols, Second Edition. Addison-Wesley, Reading, Mass.

Piper, D. 1998. "The Internet IP Security Domain of Interpretation for ISAKMP," RFC 2407 (Nov.).

Plummer, D. C. 1982. "An Ethernet Address Resolution Protocol," RFC 826 (Nov.).

Postel, J. B. 1980. "User Datagram Protocol," RFC 768 (Aug.).

Postel, J. B. 1981. "Internet Control Message Protocol," RFC 777 (Apr.).

Postel, J. B., ed. 1981a. "Internet Protocol," RFC 791 (Sept.).

Postel, J. B., ed. 1981b. "Transmission Control Protocol," RFC 793 (Sept.).

Preneel, B. and Oorschot, P. C. van 1995. "MDx-MAC and Building Fast MACs from Hash Functions," Advances in Cryptology-CRYPTO '95, Lecture Notes in Computer Science, no. 963, pp. 114, Springer-Verlag. http://www.scs.carleton.ca/~paulv/papers/Crypto95.ps

Preneel, B. and Oorschot, P. C. van 1996. "On the Security of Two MAC Algorithms," Advances in Cryptology-EUROCRYPT '96, Lecture Notes in Computer Science, no. 1070, pp. 1932, Springer-Verlag. http://www.scs.carleton.ca/~paulv/papers/Euro96-2MACs.ps

Provan, D. 1991. "Tunneling IPX Traffic through IP Networks," RFC 1234 (June).

Rekhter, Y. and Gross, P. 1995. "Application of the Border Gateway Protocol in the Internet," RFC 1772 (Mar.).

Rekhter, Y. and Li, T. 1993. "An Architecture for IP Address Allocation with CIDR," RFC 1518 (Sept.).

Rekhter, Y. and Li, T. 1995. "A Border Gateway Protocol 4 (BGP-4)," RFC 1771 (Mar.).

Rekhter, Y., Moskowitz, R. G., Karrenberg, D., Groot, G. J. de, and Lear, E. 1996. "Address Allocation of Private Internets," RFC 1918 (Feb.).

Rekhter, Y. and Rosen, E. 2001. "Carrying Label Information in BGP-4," RFC 3107 (May).

Rescorla, E. 2001. SSL and TLS: Designing and Building Secure Systems. Addison-Wesley, Boston, Mass.

Reynolds, J. K. and Postel, J. B. 1985. "File Transfer Protocol (FTP)," RFC 959 (Oct.).

Rivest, R. 1992a. "The MD4 Message-Digest Algorithm," RFC 1320 (Apr.).

Rivest, R. 1992b. "The MD5 Message-Digest Algoritm," RFC 1321 (Apr.).

Rivest, R. L., Shamir, A., and Adleman, L. M. 1978. "A Method for Obtaining Digital Signatures and Public-Key Cryptosystems," Communications of the ACM, vol. 21, no. 2, pp. 120126 (Feb.).

Robshaw, M. J. B. 1995. "Stream Ciphers," Technical Report TR-701, Version 2.0, RSA Laboratories (July). ftp://ftp.rsasecurity.com/pub/pdfs/tr701.pdf

Romkey, J. L. 1988. "A Nonstandard for Transmission of IP Datagrams Over Serial Lines: SLIP," RFC 1055 (June).

Roos, A. 1995. "A Class of Weak Keys in the RC4 Stream Cipher (Preliminary Draft)," Message-ID: <43vf2e$sr8@net.auckland.ac.nz>, Usenet, Sci.Crypt.Research (Sept.). http://groups.google.com/groups?selm=43vf2e%24sr8%40net.auckland.ac.nz&oe=UTF-8&output=gplain

Rosen, E. C. and Rekhter, Y. 1999. "BGP/MPLS VPNs," RFC 2547 (Mar.).

Rosen, E. C., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and Conta, A. 2001. "MPLS Label Stack Encoding," RFC 3032 (Jan.).

Rosen, E. C., Viswanathan, A., and Callon, R. 2001. "Multiprotocol Label Switching Architecture," RFC 3031 (Jan.).

RSA Laboratories 2002. PKCS #1 v2.1: RSA Cryptography Standard. RSA Laboratories ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1.pdf

Schneier, B. 1996. Applied Cryptography Second Edition: Protocols, Algorithms, and Source Code in C. John Wiley & Sons, N.Y.

Schneier, B. 2003. "SSL Flaw," Crypto-Gram Newsletter, Counterpane Internet Security, Inc. (Mar.). http://www.schneier.com/crypto-gram-0303.html

Schneier, B. and Mudge 1998. "Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP)," Proceeding of the 5th ACM Conference on Communications and Computer Security, pp. 132141, ACM Press. http://www.counterpane.com/pptp-paper.html

Schneier, B., Mudge, and Wagner, D. 1999. "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)," white paper. http://www.counterpane.com/pptpv2-paper.html

Shea, R. 2000. L2TP Implementation and Operation. Addison-Wesley, Reading, Mass.

Simpson, W. A. 1996. "PPP Challenge Handshake Authentication Protocol (CHAP)," RFC 1994 (Aug.).

Snader, J. C. 2000. Effective TCP/IP Programming. Addison-Wesley, Boston, Mass.

Song, D. X., Wagner, D., and Tian, X. 2001. "Timing Analysis of Keystrokes and Timing Attacks on SSH," 10th USENIX Security Symposium (Aug.). http://www.usenix.org/events/sec01/full_papers/song/song.pdf

Srisuresh, P. and Holdrege, M. 1999. "IP Network Address Translator (NAT) Terminology and Consideration," RFC 2663 (Aug.).

Stevens, W. R. 1992. Advanced Programming in the UNIX Environment. Addison-Wesley Pub. Co., Reading, Mass.

Stevens, W. R. 1994. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Pub. Co., Reading, Mass.

Stevens, W. R. 1996. TCP/IP Illustrated, Volume 3: TCP for Transactions, HTTP, NNTP, and the UNIX Domain Protocols. Addison-Wesley Pub. Co., Reading, Mass.

Stevens, W. R. 1998. UNIX Network Programming, Volume 1, Second Edition, Networking APIs: Sockets and XTI. Prentice Hall PTR, Upper Saddle River, N.J.

Stevenson, F. A. 1995. "Cracked: WINDOWS.PWL," Message-ID: <Pine.SGI.3.91.951204174641. 2847A-100000@odin>, Cypherpunks Mail List (Dec.). http://groups.google.com/groups?selm=Pine.SGI.3.91.951204174641.2847A-100000%40odin&oe=UTF-8&output=gplain

Townsley, W. M., Valencia, A. J., Rubens, A., Pall, G. S., Zorn, G., and Palter, B. 1999. "Layer Two Tunneling Protocol "L2TP"," RFC 2661 (Aug.).

Varghese, G. 2005. Network Algorithmics : An Interdisciplinary Approach to Designing Fast Networked Devices. Morgan Kaufmann, San Francisco

Vaudenay, S. 2002. "Security Flaws Induced by CBC Padding-Applications to SSL, IPSEC, WTLS. . .," Advances in Cryptology-EUROCRYPT '02, Lecture Notes in Computer Science, no. 2332, pp. 534545, Springer-Verlag. http://lasecwww.epfl.ch/pub/lasec/doc/Vau02a.ps

Viega, J., Messier, M., and Chandra, P. 2002. Network Security with OpenSSL. O'Reilly & Associates, Sebastopol, Calif.

Voydock, V. L. and Kent, S. T. 1983. "Security Mechanisms in High-Level Network Protocols," ACM Computing Surveys, vol. 15, no. 2, pp. 135171 (June).

Wagner, D. and Schneier, B. 1996. "Analysis of the SSL 3.0 protocol," The Second USENIX Workshop on Electronic Commerce Proceedings, pp. 2940 (Nov.). http://www.counterpane.com/ssl.html

Waissbein, A. and Friedman, A. A. 2001. "SSH Protocol 1.5 Session Key Recovery Vulnerability," Advisory CORE-20010116, Core Security Technologies (Feb.). http://tinyurl.com/yrzub

Wang, X., Feng, D., Lai, X., and Yu, H. 2004. "Collisions for Hash Functions MD4, MD5, HAVAL-128 and RIPEMD," white paper. http://eprint.iacr.org/2004/199.pdf

Wang, X., Yin, Y. L., and Yu, H. 2005. "Collision Search Attacks on SHA1," white paper. http://s17.yousendit.com/d.aspx?id=0MZULY5IBDAU130DK0RKV3GTIB

Wang, X. and Yu, H. 2005. "How to Break MD5 and Other Hash Functions," Preprint (Mar.). http://www.infosec.sdu.edu.cn/paper/md5-attack.pdf

Wilson, S. 2003. "Rethinking PKI," SC Magazine (June). http://www.scmagazine.com/scmagazine/2003_06/feature_2/index.html

Wright, G. R. and Stevens, W. R. 1995. TCP/IP Illustrated, Volume 2: The Implementation. Addison-Wesley Pub. Co., Reading, Mass.

Zheng, P. 2003. "Tradeoffs in Certificate Revocation Schemes," Computer Communication Review, vol. 33, no. No. 2, pp. 103112 (Apr.).

Zorn, G. and Cobb, S. 1998. "Microsoft PPP CHAP Extensions," RFC 2433 (Oct.).


Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]


SYMBOL

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

/dev/urandom device
/etc/ppp/auth-down file
/etc/ppp/auth-up file
/etc/ppp/ip-down file
/etc/ppp/ip-up file
/etc/ppp/ppp.conf file
/etc/ppp/ppp.linkdown file
/etc/ppp/ppp.linkup file
3DES (triple DES) 2nd 3rd 4th 5th 6th 7th 8th
definition of


A

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Aboba, B. 2nd 3rd 4th
accept function
access concentrator, definition of
ACCM (asynchronous control character map)
attribute value field
definition of
ACK flag, definition of
Adams, R.
address
broadcast
IPv6
limited broadcast
network-directed broadcast
private 2nd 3rd 4th 5th
Address Resolution Protocol [See ARP]
addressing
classful
IP
Adleman, L.M. 2nd 3rd
Advanced Encryption Standard [See AES]
AES (Rijndael) 2nd 3rd 4th 5th 6th 7th 8th
Agarwal, P.
aggressive mode, definition of
AH (Authentication Header protocol) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
definition of 2nd
header
header, definition of
input processing
IPsec protocol
IPv6
output processing
processing
transport mode
tunnel mode
Akyol, B.
Albaugh, T.
alert
message types, SSL
SSL
algorithm
Bellman-Ford
Dijkstra's
extended Euclidean
alleged RC4
Allen, C.
Alvestrand, H.T.
Anderson, R.
Andersson, L.
AppleTalk 2nd
application layer 2nd 3rd
definition of
arithmetic, ones-compliment
Arkko, J.
ARP (Address Resolution Protocol), definition of
assigned
session ID, definition of
tunnel AVP, definition of
asymmetric cipher 2nd 3rd 4th
asynchronous control character map [See ACCM]
Atkinson, R. 2nd 3rd 4th 5th 6th 7th
attack
DOS
Smurf
2nd [See AVP]
auth-up file
authentication 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th
Authentication Header protocol [See AH]
authentication, VTun
2nd 3rd 4th 5th 6th [See AS]
avalanche effect, definition of
AVP (attribute value pair)
definition of
HELLO
L2TP message type
Result code
AVPs
CDN
ICCN
ICRP
ICRQ
OCCN
OCRP
OCRQ
SCCCN
SCCRP
SCCRQ
SLI
SopCCN
WEN


B

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Barrett, D.J. 2nd 3rd
bash program
Baugher, M.
Baze, M.
bc program 2nd
bearer
capabilities, definition of
type, definition of
Begley, L.
Bellare, M. 2nd 3rd 4th 5th 6th
Bellman-Ford algorithm
Bellovin, S.M. 2nd
Bentley, J.
BGP (Border Gateway Protocol) 2nd 3rd
birthday paradox 2nd
bit-flipping, definition of
BITS (bump-in-the-stack), definition of
BITW (bump-in-the-wire), definition of
Bleichenbacher, D. 2nd
block cipher 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
Blowfish 2nd 3rd 4th 5th 6th 7th 8th 9th
Blunk, L.J.
Boneh, D.
Booth, S.
BOOTP
Border Gateway Protocol [See BGP]
border router, definition of
Borman, D.
Braden, R.T.
broadcast address
Brumley, D.
BSD r-commands 2nd 3rd 4th
bsd work station 2nd
bump-in-the-stack [See BITS]
bump-in-the-wire [See BITW]


C

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

CA (certificate authority) 2nd 3rd 4th 5th 6th
definition of
call serial number, definition of
called number, definition of
calling number, definition of
Callon, R.
Canetti, R. 2nd 3rd 4th
Canvel, B.
Carlson, J. 2nd 3rd 4th 5th
Carrel, D. 2nd
cat program
CBC mode, definition of
CCP (Compression Control Protocol), definition of
CDN AVPs
certificate 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
chain
revocation
SSL 2nd 3rd 4th 5th 6th 7th 8th
types, IKE
X.509
certificate authority [See CA]
CFB (cipher feedback mode), definition of
challenge, definition of
Challenge-Handshake Authentication Protocol [See CHAP]
Chandra, P.
change cipher spec, SSL
channel messages, SSHv2
CHAP (Challenge-Handshake Authentication Protocol), definition of
Cheval, P.
CIDR (classless interdomain routing) 2nd 3rd
CIPE 2nd 3rd 4th 5th
binary packet
binary packet, definition of
configuration data, definition of
control message types
control messages
key exchange packet, definition of
key exchange types
key negotiation
P byte, definition of
security
ciped program 2nd
cipher
asymmetric 2nd 3rd 4th
block 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
Feistel 2nd
stream 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
suite, SSL
symmetric 2nd 3rd 4th
cipher block chaining mode [See CBC]
cipher feedback mode [See CFB]
Clark, J.
classful
address ranges
addressing
classless interdomain routing [See CIDR]
client
authentication, SSL
hello, SSL
key exchange, SSL
closure notification, SSL
Cobb, S.
combined
mode cryptographic algorithms
security associations
Comer, D.E. 2nd
Compression Control Protocol [See CCP]
computationally infeasible, definition of
connection
set up
shutdown
connection-based 2nd
connectionless 2nd 3rd
definition of
conservative label retention mode, definition of
Conta, A.
control messages
L2TP
PPTP
counter mode [See CTR]
CRC (cyclic redundancy check) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
CRC-32 compensation attack detector
Crocker, S.D.
cryptographic
hash function
implementations
cryptographically secure random number
cryptography 2nd
elliptic curve
csh program
CTR mode, definition of
cyclic redundancy check [See CRC]


D

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Dai, W.
Data Encryption Standard [See DES]
Datagram Transport Layer Security [See DTLS]
datalink layer, definition of
Davari, S.
Davie, B.
Davis, C.R.
Dawson, E.
dc1 device
de Groot, J.G.
de Wegner, B.
decorrelation, definition of
Deep Crack
Deering, S.
Deering, S.E. 2nd
denial of service [See DOS]
DES (Data Encryption Standard) 2nd 3rd 4th 5th
DHCP (Dynamic Host Configuration Protocol) 2nd
DiBurro, L. 2nd
Dierks, T.
Diffie, W. 2nd 3rd
Diffie-Hellman key
exchange 2nd 3rd
exchange, SSL
digital signature 2nd 3rd 4th 5th 6th 7th 8th
Digital Signature Algorithm [See DSA]
Digital Signature Standard [See DSS]
Digital Subscriber Line [See DSL]
Dijkstra, E.W.
Dijkstra's algorithm
discrete logarithm 2nd
DISPLAY variable
distance vector protocol 2nd
Dixon, W. 2nd 3rd
DNS (Domain Name System) 2nd 3rd 4th 5th
DOI (Domain of Interpretation), definition of
Domain Name System [See DNS]
Domain of Interpretation [See DOI]
Dommety, G.
Doolan, P.
Doraswamy, N. 2nd
DOS (denial of service) 2nd 3rd
attack
downstream on demand mode, definition of
Dreyfus, S.
DSA (Digital Signature Algorithm) 2nd
DSL (Digital Subscriber Line)
definition of
DSS (Digital Signature Standard) 2nd 3rd 4th
definition of
DTLS (Datagram Transport Layer Security), definition of
Dynamic Host Configuration Protocol [See DHCP]


E

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

EAP (Extensible Authenication Protocol), definition of
Eastlake, D.E., 3rd
EBC mode, definition of
echo
function
program
echoit program 2nd
ECP, definition of
EDE mode, definition of
Effective TCP/IP Programming [See ETCP]
Egevang, K.B.
EGP (Exterior Gateway Protocol)
definition of
egress router, definition of
EIGRP (Enhanced Interior Gateway Routing Protocol)
electronic code book mode [See ECB]
Electronic Frontier Foundation
ElGamal 2nd 3rd 4th 5th
ElGamal, T.
elliptic curve cryptography
Encapsulating Security Payload [See ESP]
encapsulation 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd
encrypt-decrypt-encrypt mode [See EDE]
encryption 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st
symmetric
endpoint authentication, definition of
Enhanced Interior Gateway Routing Protocol [See EIGRP]
errno variable
error codes, L2TP
error function 2nd 3rd
ERROR macro
ESN (extended sequence number), definition of
ESP (Encapsulating Security Payload) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd
definition of 2nd
header
header/trailer, definition of
input processing
IPsec protocol
IPv6
output processing
processing
transport mode
tunnel mode
ESPv3
header, definition of
ETCP ({Effective TCP/IP Programming}) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
eth1 device
ethereal program
etherpeek program
Etienne, J.
Evarts, J.
exchange types, IKE
exec function
execl function
explicit congestion notification [See ECN]
extended
Euclidean algorithm 2nd
sequence numbers
extended sequence number [See ESN]
Extensible Authenication Protocol [See EAP]
extension headers, IPv6 2nd
Exterior Gateway Protocol [See EGP] [See EGP]


F

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Farinacci, D. 2nd
FCS (frame check sequence) 2nd
FEC (forwarding equivalence class), definition of
FEC to NHLFE map [See FTN]
Fedorkow, G.
Feistel cipher (Feistel network) 2nd
definition of
Feistel network [See Feistel cipher]
Feldman, N.
Feng, D.
Ferguson, N. 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
Fermat's little theorem
FIN flag, definition of
finished message, SSL
flooding, definition of
Fluhrer, S. 2nd
Ford, L.R.
Ford, W.
fork function 2nd
forwarding equivalence class [See FEC]
four-way handshake
frame check sequence [See FCS]
frame formats, PPP
framing
capabilities, definition of
type, definition of
Francis, P.
Franz, M.
Fredette, A.
Freier, A.O.
Friedman, A.A.
FTN (FEC to NHLFE map), definition of
ftp program 2nd 3rd 4th 5th
FTP, definition of
Fulkerson, D.R.
Fuller, V.
function, cryptographic hash
Futoransky, A. 2nd


G

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Garman, J.
GCHQ (Government Communications Headquarters)
general authentication messages, SSH
Generic Routing Encapsulation [See GRE]
geqn program
gethostbyname function
gif device 2nd
Glenn, R. 2nd
Goldberg, I.
Government Communications Headquarters [See GCHQ]
gpic program
GRE (Generic Routing Encapsulation) 2nd 3rd 4th 5th
definition of
gre device
GRE header, definition of
gretun device
Gross, P.
group generator, definition of
gtbl program
gtunnel
program 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
gtunnel.c file 2nd
Guichard, J.
Gutmann, P. 2nd 3rd 4th 5th 6th 7th


H

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

half close
Haller, N.M.
Hamzeh, K.
handshake
four-way
messages, SSL
three-way
types, SSL
Hanks, S.
Hanson, D.
Harding, T.
Hardjono, T.
Harkins, D. 2nd 3rd
Harney, H.
hash function, cryptographic
Hatch, B.
HDLC (High-Level Data Link Control Protocol) 2nd 3rd
definition of
header
AH
IP
IPv6
TCP
UDP
Hedrick, C.
Heinanen, J.
Hellman, M. 2nd 3rd
HELLO
AVP
definition of
hello done, SSL
Henry-Stocker, S.
Herzog, J.
Hickman, K.E.B.
hidden AVP, definition of
High-Level Data Link Control Protocol [See HDLC]
Hiltgen, A.
Hinden, R.M. 2nd 3rd
HMAC 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd
Holdrege, M.
Hollenbeck, S.
host ID, definition of
Housley, R.
Huitema, C. 2nd
Huttunen, A. 2nd


I

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

IANA (Internet Assigned Numbers Authority), definition of
ICCN AVPs
ICMP (Internet Control Message Protocol) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd
definition of
echo reply
echo request
error messages
message types
protocol
ICRP AVPs
ICRQ AVPs
identification
payload, IPsec
types, IPsec
IETF (Internet Engineering Task Force) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
ifconfig program 2nd 3rd
IGMP (Internet Group Management Protocol)
IGP (Interior Gateway Protocol) 2nd
definition of
IKE (Internet Key Exchange) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
authentication with signatures
certificate types
definition of 2nd 3rd
exchange types
IPsec protocol
key generation
new group exchange
notification message types
payload types
phase 1
phase 1 attributes
phase 2 attributes
phase 2 quick mode
public key authentication
revised public key authentication
shared secret authentication
IKEv2 2nd 3rd
exchanges
messages
ILM (incoming label map), definition of
inbound function 2nd 3rd
incoming label map [See ILM]
inet_aton function
inetd program
inetd. program
ingress router, definition of
INIT macro 2nd
initial received LCP CONFREQ, definition of
initialization vector [See IV]
Integrated Services Digital Network [See ISDN]
integrity check value [See ICV]
interface layer 2nd 3rd 4th 5th
definition of
Interior Gateway Protocol [See IGP]
Intermediate System to Intermediate System Protocol [See IS-IS]
International Telecommunication Union
Internet Assigned Numbers Authority [See IANA]
Internet Control Message Protocol [See ICMP]
Internet Engineering Task Force [See IETF]
Internet Group Management Protocol [See IGMP]
Internet Key Exchange [See IKE]
Internet layer, definition of
Internet Protocol [See IP]
internet protocol numbers
Internet Security Association and Key Management Protocol [See ISAKMP]
internet service provider [See ISP]
Ioannidis, J.
IP (Internet Protocol)
addressing
header
layer
ip program
IP protocol
IP security [See IPsec]
ip variable
IP-in-IP tunnel 2nd 3rd 4th 5th 6th 7th 8th 9th
ip-up file
ip_len member
ip_p member
ipip program 2nd
ipip.c file
IPPROTO_IPIP socket option
IPsec (IP security) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd 34th 35th 36th 37th 38th
and multicast
architecture 2nd
definition of
futures
ICMP processing
identification payload
identification types
inbound processing
modes
outbound processing
overview
policies
policy, definition of
processing
protocol IDs
protocol, AH
protocol, ESP
protocol, IKE
protocols
selectors, definition of
sequence numbers
transform IDs
iptrace program
IPv4, definition of
IPv6 2nd 3rd 4th 5th 6th 7th 8th
address
AH
anycast address, definition of
definition of
ESP
extension headers 2nd
header
muticast address, definition of
pseudoheader, definition of
unicast address, definition of
IPX 2nd 3rd
IS-IS (Intermediate System to Intermediate System Protocol)
ISAKMP (Internet Security Association and Key Management Protocol) 2nd 3rd 4th
attribute, definition of
certificate payload
certificate payload, definition of
certificate request, definition of
cookies
delete payload
delete payload, definition of
generic header, definition of
hash payload
hash payload, definition of
header
header, definition of
identification payload
key exchange payload
key exchange payload, definition of
message processing
nonce payload
nonce payload, definition of
notification payload
notification payload, definition of
payloads
proposal payload, definition of 2nd
SA payload, definition of
signature payload
signature payload, definition of
transform payload, definition of
vendor ID payload, definition of
vendor payload
ISDN (Integrated Services Digital Network), definition of
iterated tunneling, definition of
IV (initialization vector), definition of


J

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Jacobson, V.
Johnson, D.B.


K

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Kalisky, B. 2nd
Kargieman, E. 2nd
Karlton, P.
Karrenberg, D.
Kaufman, C.
Kent, S. 2nd 3rd 4th 5th 6th 7th 8th
kermit program
Kernighan, B.
key management
Kivinen, T. 2nd
Klima, V.
Knuth, D.E. 2nd
Kocker, P.C.
Kohno, T. 2nd
Kolesnikov, O.
Krawczyk, H. 2nd 3rd 4th 5th 6th
Krishnan, R.


L

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

L2F (Layer Two Forwarding), definition of
L2TP (Layer Two Tunneling Protocol) 2nd 3rd 4th 5th 6th
attribute value pair, definition of
AVP, definition of
common header, definition of
control messages
definition of
error codes
message type AVP
proxy authentication types
L2TP Access Concentrator [See LAC]
L2TP Network Server [See LNS]
L2TPv3
label
distribution protocol
MPLS
label distribution protocol [See LDP]
label switched path [See LSP]
label switching router [See LSR]
LAC (L2TP Access Concentrator), definition of
Lai, X.
LANalyzer program
laptop work station 2nd 3rd
last
received LCP CONFREQ, definition of
sent LCP CONFREQ, definition of
Layer Two Forwarding [See L2F]
Layer Two Tunneling Protocol [See L2TP]
layering 2nd 3rd
LCP (Link Control Protocol), definition of
LDP (label distribution protocol), definition of
Le Faucheur, F.
Lear, E.
leased line 2nd 3rd 4th 5th 6th
Lemberg, W.
Lenstra, A.
Levkowetz, H.
Li, T. 2nd 3rd 4th
liberal retention mode, definition of
Lidl, K.
lightweight VPN 2nd 3rd 4th
limited broadcast address
Link Control Protocol [See LCP]
link layer 2nd 3rd
definition of
link-state protocol 2nd
linux work station 2nd 3rd 4th
linuxlt work station
Little, W.A.
LNS (L2TP Network Server), definition of
logarithm, discrete 2nd
loom program
LSP (label switched path), definition of
LSR (label switching router), definition of


M

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

MAC (message authentication code) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th
address
address, definition of
definition of
Madson, C. 2nd
Main mode, definition of
Malkin, G.S.
Mamakos, L.
mandatory mode, definition of
Mantin, I. 2nd
manual keying, definition of
Maughan, D.
maximum bps, definition of
maximum receive unit [See MRU]
maximum transmission unit [See MTU]
McLaughlin, R.
MD5 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
md5 program
Menezes, A.J. 2nd 3rd
Merkle, R.
message
authentication, definition of
types, SSHv1
message authentication code [See MAC]
message integrity code [See MIC]
Messier, M.
Messmer, E.
Meyer, D.
MH (mobility header), definition of
MIC (message integrity code), definition of
Microsoft Challenge Handshake Authentication Protocol [See MS-CHAP]
Microsoft Point-to-Point Encryption [See MPPE]
minimum bps, definition of
Mister, S.
mobility header [See MH]
Modadugu, N.
mode
transport
tunnel
modes, IPsec
Mogul, J. 2nd
Moskowitz, R.G.
Moy, J.
MPLS (Multiprotocol Label Switching) 2nd 3rd
definition of
label
tunnel
VPN 2nd
MPPE (Microsoft Point-to-Point Encryption)
MRU (maximum receive unit)
ms macro
MS-CHAP (Microsoft Challenge Handshake Authentication Protocol) 2nd
MTU (maximum transmission unit) 2nd 3rd 4th 5th 6th 7th 8th
Mudge
multicast
Multiprotocol Label Switching [See MPLS]
mutable
but predictable
IP header fields (AH), definition of
IPv6 header fields (AH), definition of


N

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Nadeau, T.D.
Namprempre, C. 2nd
NAP (network access point)
definition of
Narten, T.
NAT (network address translation) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
keep-alives
NAT transversal [See NAT-T]
NAT-D payload, definition of
NAT-OA payload, definition of
NAT-T (NAT transversal) 2nd 3rd 4th 5th 6th 7th
definition of 2nd
National Security Agency [See NSA]
nc program 2nd
NCP (Network Control Protocol), definition of
netcat 2nd 3rd 4th 5th
command line options
nettl program
network
ID, definition of
layer 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
layer, definition of
network access point [See NAP]
network address translation [See NAT]
Network Control Protocol [See NCP]
Network Layer Security Protocol [See NLSP]
network traces
network-directed broadcast address
new IPsec processing model
newmail function
next hop label forwarding entry [See NHLFE]
NHLFE (next hop label forwarding entry), definition of
Nielsen, L.
NIST 2nd 3rd 4th
NLSP (Network Layer Security Protocol), definition of
Nolan, C.
nonce, definition of
Nordmark, E.
notification
message types, IKE
payload, ISAKMP
notify function
NSA (National Security Agency) 2nd


O

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Oakley Key Determination Protocol [See OAKLEY]
OCCN AVPs
OCRP AVPs
OCRQ AVPs
OFB (output feedback mode), definition of
one time pad
ones-compliment arithmetic
open failure reason codes, SSHv2
Open Shortest Path First Protocol [See OSPF]
Open Systems Interconnection [See OSI]
OpenSSH 2nd 3rd 4th 5th 6th 7th
OpenSSL 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
openssl program
OpenVPN 2nd 3rd 4th 5th
control channel
control channel packet, definition of
data channel
data packet, definition of
key exchange message-1, definition of
key exchange message-2, definition of
OCC message, definition of
OCC op codes
op codes
packet header, definition of
ping and OCC protocols
security
security models
optional ESP padding
orderly release
Orman, H.K.
OSI reference model
OSPF (Open Shortest Path First Protocol) 2nd 3rd
outbound function 2nd 3rd
output feedback mode [See OFB]


P

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

PAC (PPTP Access Concentrator), definition of
Pacetti, A.M. 2nd
packet
PPP
sniffers
types, PPPoE
PAD (peer authentication database)
definition of
PADI (PPPoE Active Discovery Initiation)
definition of
PADO (PPPoE Active Discovery Offer)
definition of
PADR (PPPoE Active Discovery Request)
definition of
PADS (PPPoE Active Discovery Session-confirmation)
definition of
PADT (PPPoE Active Discovery Terminate)
definition of
Pall, G.S. 2nd 3rd 4th
Palter, B. 2nd
PAP (Password Authentication Protocol), definition of
Partridge, C.
Password Authentication Protocol [See PAP]
Patel, B.V.
path MTU [See PMTU]
path-vector protocol
payload types, IKE
PCT (Private Communications Technology), definition of
peer authentication database [See PAD]
penultimate hop popping, definition of
Pepelnjak, I.
Pereira, R.
perfect forward secrecy [See PFS]
Perkins, C. 2nd
Perkins, C.E.
Perlman, R. 2nd 3rd 4th
PFP (populate from packet flags), definition of
PFS (perfect forward secrecy), definition of
phase
1 attributes, IKE
2 attributes, IKE
physical channel ID, definition of
pid variable
ping program 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th
Piper, D.
PKCIPE
message types
packet, definition of
pkcipe
pkcipe program 2nd
PKCS #1 2nd
PKI (public key infrastructure)
definition of
Plummer, D.C.
PMTU (path MTU) 2nd 3rd
PNS (PPTP Network Server), definition of
Point to Point Protocol [See PPP]
Point to Point Tunneling Protocol [See PPTP]
policies, IPsec
Polk, T.
pooled mode, definition of
popen function
populate from packet flags [See PFP]
port
address translation, definition of
forwarding, SSH
port address translation [See PAT]
Postel, J.B. 2nd 3rd 4th 5th 6th
PPP (Point to Point Protocol) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th
frame formats
packet
PPP over Ethernet [See PPPoE]
ppp program 2nd
ppp.conf file 2nd
ppp.linkup file
pppd
command line options
program 2nd 3rd 4th 5th
PPPoE (PPP over Ethernet) 2nd 3rd
header, definition of
packet types
PPPoE Active Discovery Initiation [See PADI]
PPPoE Active Discovery Offer [See PADO]
PPPoE Active Discovery Request [See PADR]
PPPoE Active Discovery Session-confirmation [See PADS]
PPPoE Active Discovery Terminate [See PADT]
pppoe program
PPPoE tag
PPPoe, definition of
PPTP (Point to Point Tunneling Protocol) 2nd 3rd 4th 5th 6th 7th
control message header, definition of
control messages
definition of
extended GRE header, definition of
PPTP Access Concentrator [See PAC]
PPTP Network Server [See PNS]
Preneel, B.
printf function
private
group, definition of
peering
private address 2nd 3rd 4th 5th
ranges
Private Communications Technology [See PCT]
protocol
distance vector 2nd
ICMP
IDs, IPsec
IP
label distribution
link-state 2nd
path-vector
TCP
UDP
version, definition of
protocols, IPsec
Provan, D.
proxy
ARP, definition of
authen challenge, definition of
authen ID, definition of
authen name, definition of
authen response, definition of
authen type, definition of
pseudo-header 2nd
pseudo-randomness, definition of
pseudowire
PSH flag, definition of
public key infrastructure [See PKI]
public key signature data, SSHv2
Pyle, E.
python program 2nd 3rd 4th 5th


Q

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Quick mode, definition of


R

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

rand function 2nd
random
device, definition of
vector, definition of
random device
random/urandom device
RAS (remote access server), definition of
rbiff program
rbiffd program 2nd
RC4 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
alleged
rcp program 2nd
read function 2nd
receive window, definition of
record layer
message types, SSL
SSL
recv_char() program
reference model, OSI
Rekhter, Y. 2nd 3rd 4th 5th 6th
reliable 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
remote access server [See RAS]
remote variable
Rescorla, E. 2nd 3rd 4th 5th 6th
Result code AVP
result codes, StopCCN
resumed session, SSL
rexec program
Reynold, J.K.
Rijndael [See AES]
RIP
Rivest, R. 2nd 3rd 4th 5th
rlogin program
Robshaw, M. 2nd
Romkey, J.L.
Roos, A.
rootcert.pem file
Rosen, E.C. 2nd
round keys
round trip time [See RTT]
route program
routing 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
RSA 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
Laboratories 2nd
rsh program 2nd
RST flag, definition of
RTT (round trip time)
Rubens, A. 2nd
Rx connect speed, definition of


S

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

S-box (substitution box), definition of
s_client program 2nd
s_server program
SA (security association) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
definition of 2nd
proposal and transform payloads
SAD (security association database), definition of
SCCCN AVPs
SCCRP AVPs
SCCRQ AVPs
Schertler, M.
Schiller, J.I.
Schneider, M.
Schneier, B. 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
SCP (Secure Copy Program)
scp program 2nd 3rd 4th
Secure Copy Program [See SCP]
Secure Data Network System [See SP3]
Secure Hash Algorithm [See SHA]
Secure Shell [See SSH]
Secure Sockets Layer [See SSL]
security association 3rd 4th 5th 6th 7th 8th [See SA]
security association database [See SAD]
security parameter index [See SPI]
security policy database [See SPD]
select function 2nd
send_char() program
sendto function
SEQ_LT macro
SEQ_LT, definition of
sequencing required, definition of
Serial Line Protocol [See SLIP]
server
hello, SSL
key, SSH
session
key generation, SSHv2
key, definition of
set link info message [See SLI]
setkey program 2nd
sftp program
sh program
SHA (Secure Hash Algorithm) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st
Shamir, A. 2nd 3rd 4th 5th
Shea, R. 2nd
SHELL variable
shortest path, definition of
signature, digital 2nd 3rd 4th 5th 6th 7th 8th
Silverman, R.E.
Simone, D.
Simpson, W.A. 2nd
Siverman, R.E. 2nd
sleep function
SLI (set link info message)
AVPs
definition of
SLIP (Serial Line Protocol) 2nd
Smurf attack
Snader, J.C.
Snader, M
Snader, R.
snoop program
SOCK_RAW socket option
SOCKADDR macro
sockaddr structure
sockaddr_in structure
soft state 2nd
solaris work station 2nd 3rd
Solo, D.
Song, D.X.
SopCCN AVPs
SP3 (Secure Data Network System), definition of
Spam
SPD (security policy database)
definition of
Speciner, M.
SPI (security parameter index), definition of
Srisuresh, P.
SSH (Secure Shell) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th
general authentication messages
port forwarding
server key
VPN
ssh program 2nd 3rd 4th 5th 6th 7th 8th
SSH_CMSG_PORT_FORWARD_REQUEST, definition of
SSH_CMSG_REQUEST_PTY, definition of
SSH_CMSG_SESSION_KEY, definition of
SSH_CMSG_X11_REQUEST_FORWARDING, definition of
SSH_MSG_CHANNEL_DATA, definition of
SSH_MSG_CHANNEL_EXTENDED_DATA, definition of
SSH_MSG_CHANNEL_OPEN, definition of
SSH_MSG_CHANNEL_OPEN_CONFIRMATION, definition of 2nd
SSH_MSG_CHANNEL_OPEN_FAILURE, definition of
SSH_MSG_CHANNEL_REQUEST, definition of
SSH_MSG_GLOBAL_REQUEST, definition of
SSH_MSG_KEXDH_GEX_REPLY, definition of
SSH_MSG_KEXDH_REQUEST, definition of
SSH_MSG_KEXINIT, definition of
SSH_MSG_PORT_OPEN, definition of
SSH_MSG_USERAUTH_FAILURE, definition of
SSH_MSG_USERAUTH_INFO_REQUEST, definition of
SSH_MSG_USERAUTH_INFO_RESPONSE, definition of
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, definition of
SSH_SMSG_PUBLIC_KEY, definition of
sshd program 2nd 3rd 4th 5th 6th
SSHv1
authentication
binary packet, definition of
message types
remote commands
security
user authentication
SSHv2
authentication
binary packet, definition of
channel messages
connection protocol
data transfer
Diffie-Hellman key exchange
exchange hash
key generation
keyboard interactive authentication
none authentication
open failure reason codes
parameter negotiation
password authentication
port forwarding
public key authentication
public key signature data
remote commands
security
services
session key generation
subsystems
transport message types
transport protocol
user authentication request, definition of
sshvpn
program
SSL (Secure Sockets Layer) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th
alert
alert message types
alert message, definition of
certificate 2nd 3rd 4th 5th 6th 7th 8th
certificate message, definition of
change cipher spec
cipher suite
cipher suite, definition of
cipher suites
client authentication
client cert. request, definition of
client hello
client hello, definition of
client key exchange
client key exchange message, definition of
closure notification
definition of
Diffie-Hellman key exchange
finished message
finished message, definition of
handshake header, definition of
handshake messages
handshake types
hello done
MasterSecret, definition of
PreMasterSecret, definition of
protocol
record format, definition of
record layer
record layer message types
resumed session
security
server hello
server hello done, definition of
server hello, definition of
server key exchange message, definition of
v2 client hello
v2 record-client hello, definition of
VPN
SSL_accept function
SSL_read function 2nd
SSL_set_bio function
SSL_write function
ssldump
ssldump program 2nd 3rd 4th 5th 6th 7th
sslecho program 2nd 3rd
sslecho.pem file
stack
definition of
TCP/IP
Staddon, J. 2nd
startup function 2nd
static mode, definition of
Stenberg, M. 2nd
Stevens, W.R. 2nd 3rd 4th 5th 6th
Stevenson, F.A.
StopCCN result codes
stream cipher 2nd 3rd 4th 5th 6th 7th 8th 9th 10th
strerror function
strong collision resistance, definition of
stunnel
program 2nd 3rd 4th
stunnel. program
stunnel.client file
stunnel.server file 2nd
subaddress, definition of
subnetting
substitution box [See S-box]
subsystems, SSHv2
Swander, B. 2nd
symmetric
cipher 2nd 3rd 4th
encryption
SYN flag, definition of
synchronization segment [See SYN]
synchronization segment, definition of
synchronous line


T

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Taarud, J.
tag, PPPoE
Tappan, D.
tar program
Tavares, S.E.
TCP (Transmission Control Protocol)
data delivery
definition of
header
protocol
segment, definition of
TCP/IP
stack
tcp_client function
tcp_server function 2nd
tcpdump program 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th
telnet program 2nd 3rd 4th 5th 6th 7th
testbed
TFC (traffic flow confidentiality), definition of
Thomas, B.
three-way handshake
Tian, X.
tie breaker, definition of
time to live [See TTL]
tinc 2nd 3rd 4th 5th 6th
binary packet, definition of
binary protocol
metaprotocol
metaprotocol message types
security
TLS (Transport Layer Security) 2nd 3rd
definition of
tohex function
Townsley, W.M. 2nd
traces, network
traffic
analysis, definition of
selectors
traffic flow confidentiality [See TFC]
Traina, P.
transform IDs, IPsec
Transmission Control Protocol [See TCP]
transport
adjacency, definition of
layer 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
layer, definition of
message types, SSHv2
mode
Transport Layer Security [See TLS]
triple DES [See 3DES]
TTL (time to live) 2nd 3rd 4th 5th 6th
tun device 2nd 3rd 4th 5th 6th
TUN/TAP device
tun/tap device 2nd 3rd
tun0 device 2nd
tunnel 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd
definition of
IP-in-IP 2nd 3rd 4th 5th 6th 7th 8th 9th
mode
MPLS
tunneling 2nd 3rd 4th
definition of
Turner, J.
Tx connect speed, definition of


U

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

UDP (User Datagram Protocol)
definition of 2nd
header
protocol
UNIX 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
unreliable, definition of
unsolicited downstream mode, definition of
unsolicited email [See SPAM]
urandom device
urandom device, definition of
URG flag, definition of
User Datagram Protocol [See UDP]


V

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Vaananen, P.
Valencia, A.J. 2nd
van Oorschot, P.C. 2nd 3rd 4th
Vanstone, S.A. 2nd 3rd
Varadhan, K.
Varghese, G.
Vaudenay, S.
Verthein, W.
Viega, J.
virtual private network [See VPN]
Viswanathan, A.
Vollbrecht, J.R.
Volpe, V. 2nd
voluntary mode, definition of
Voydock, V.L.
VPN (virtual private network) 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th 19th 20th 21st 22nd 23rd 24th 25th 26th 27th 28th 29th 30th 31st 32nd 33rd
definition of
lightweight 2nd 3rd 4th
MPLS 2nd
SSH
SSL
VTun 2nd 3rd 4th 5th 6th 7th
authentication
security
tunnel parameter options
vtund program
Vuagnoux, M.


W

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Wagner, D. 2nd 3rd 4th
Waissbein, A.
WAN error notify message [See WEN]
Wang, X.
Weis, B.
WEN (WAN error notify message)
AVPs
definition of
WEP (wired equivalent privacy), definition of
Wheeler, R.
Wilson, S.
wired equivalent privacy [See WEP]
Wright, G.
write function
Wu, L.


X

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

X.509
certificate
certificate, definition of
X11 forwarding 2nd 3rd 4th


Y

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

Yin, Y.L.
Ylönen, T.
Yu
Yu, H.
Yu, J.


Z

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]

zero length body message [See ZLB]
Zheng, P.
ZLB message, definition of
Zorn, G. 2nd 3rd 4th 5th