Chapter 4: A Virtualization Technologies Primer: Theory

Cisco Press

1 2 3 4 5 Page 3
Page 3 of 5

The tunnel source and tunnel destination addresses are part of the transport network address space. They need to match on both endpoints so that a source address on one router is the destination address on the remote device. The router must also have a path in its routing table to the tunnel destination address. The next hop to the tunnel destination must point to a real interface and not the tunnel interface.

In this case, the router has a tunnel interface with tunnel destination of on the public network. The network used for the tunnel IP's address, however, is part of the private address space used on Sites 1 and 2.


IPsec provides a comprehensive suite of security services for IP networks. IPsec was originally conceived to provide secure transport over IP networks. The security services include strong authentication (Authentication Header [AH]) and Encryption (Header [EH]) protocols and ciphers and key-exchange mechanisms. IPsec provides a way for peers to interoperate by negotiating capabilities and keys and security algorithms.

IPsec peers maintain a database of security associations. A security association (SA) is a contract between peers, which defines the following:

  • The specific encryption and authentication algorithms used, such as Triple DES (Triple Data Encryption Standard)

  • The IPsec protocol service (Encapsulating Security Payload [ESP] or AH)

  • Key material needed to communicate with the peer

The SA is negotiated when an IPsec session is initiated. Each IPsec header contains a unique reference to the SA for this packet in a Security Parameter Index (SPI) field, which is 32-bit numeric reference to the SA needed to process the packet. Peers maintain a list of SAs for inbound and outbound processing. The value of the SPI is shared between peers. It is one of the things exchanged during IPsec session negotiation.

At the protocol level, there are two IPsec headers:

  • AH—Offers nonrepudiatable authentication between two parties. The authentication service also provides for message integrity and certain instances of (identity) spoofing.

  • ESP—Offers encrypted communication between two parties. The encryption service allows message confidentiality, integrity, nonrepudiation, and protection against spoofing and replay attacks.

It is possible to use authentication and encryption services separately or together. If used in combination, the AH header precedes the ESP header.

There are two ways to encapsulate IPsec packets. The first, called tunnel mode, encrypts an entire IP packet, including the header, in the IPsec payload. A new IP header is generated for the encrypted packet, as shown in Figure 4-7.

Figure 4.7

Figure 4-7

IPsec Tunnel Mode Stack

Tunnel mode adds a 20-octet overload with the new IP header. To reduce issues with packet size and fragmentation, a second mode was defined, called transport mode. Transport mode just protects the TCP/UDP layer and is shown in Figure 4-8. Tunnel mode is better than transport mode at traversing Network Address Translation (NAT) devices.

Figure 4.8

Figure 4-8

IPsec Transport Mode Stack

IPsec requires a lot of negotiation to bring up a session. So much so that there is a separate control channel protocol, called Internet Key Exchange (IKE), used to negotiate the SA between peers and exchange keys material. Note that IKE is not mandatory; you can statically configure the SAs.

IKE is not only used during tunnel setup. During confidential data exchange, the session keys used to protect unidirectional traffic may need to be changed regularly, and IKE is used to negotiate new keys.

IKE traffic itself is encrypted, and, in fact, it has its own SA. Most of the parameters are fixed as follows:

  • 56-bit DES for encryption

  • Message digest 5 (MD5) algorithm or secure hash algorithm (SHA) hashing

  • Rivest, Shamir, Adleman (RSA) (public key) signatures or preshared keys

IKE runs on UDP/500. IPsec uses IP protocol values of 50 and 51.

Cisco IOS IPsec Configuration

There is a lot more to IPsec than you will see here, but there are three basic parts to the configuration, which correspond to setting up SAs first for IKE, and then for the session itself, and defining which traffic to encrypt. The steps of the configuration are as follows:

  1. The first basic part is the IKE policy. IKE will negotiate its own SA with the remote peer, so it too needs a policy. The crypto isakamp policy command defines the type of authentication, and the IP address of the remote peer and the shared secret used to protect the IKE exchanges, as indicated in Example 4-8.

  2. Example 4-8  IKE Policy Settings

    crypto isakmp policy 1
     authentication pre-share
    crypto isakmp key secret address
  3. In the second basic part is a crypto map, the role of the crypto map is to define the remote peer, the encryption and authentication algorithms (called transforms) that this router will accept to set up a SA, and the interesting traffic to be encrypted. As in so much of Cisco IOS, interesting traffic is defined using standard access lists. If a packet matches an access list entry, whatever IPsec policy is defined in the crypto map is applied to the packet. Example 4-9 has a crypto map that configures any traffic to address that matches access list 101 to be encrypted using the IPsec service called ONE.

  4. Example 4-9  IPsec Crypto Map

    crypto map VPN 1 IPsec-isakmp 
     set peer
     set security-association lifetime seconds 180
     set transform-set ONE
     match address 101

    The authentication and encryption algorithms for this SA are defined in a transform set (so they can be shared between multiple SA definitions). The transform set is given in Example 4-10. It specifies AH and ESP services, with MD5 for authentication and DES for encryption.

    Example 4-10 IPsec Transform Set

    crypto ipsec transform-set ONE ah-md5-hmac esp-des
  5. The third step is to apply the crypto map on an outgoing interface, as in Example 4-11. This completes the puzzle. Now when packets enter or leave the Serial0 interface on this router, they are compared against access list 101 (refer back to the crypto map in Example 4-9), and if there is a match, encrypted according to the service defined in Example 4-10.

  6. Example 4-11  Interface with Crypto Map

    interface Serial0
     ip address
     no ip mroute-cache
     no fair-queue
     crypto map VPN


Note - Appendix A contains an expanded version of this section that discusses the L2TPv3 protocol in more detail.

The L2TPv3 protocol consists of components to bring up, maintain, and tear down sessions, and the capability to multiplex different Layer 2 streams into a tunnel.

The L2TP protocol has a both a control and data plane. The control channel is reliable. There are 15 different control message types. The major ones are for the setup and teardown of the control channel itself (see Appendix A for more detail). L2TPv3 peers can exchange capability information for the session during the setup phase. The most important of these are the session ID and cookie.

The session ID is analogous to the control channel identifier and it is a "shortcut" value that the receiver associates with the negotiated context for a particular session (for instance, payload type, cookie size, and so forth).

The cookie is an optional, variable-length field of up to 64 bits. The cookie is a cryptographically random number that extends the session identifier space so as to ensure there is little chance that a packet is misdirected because of corrupt session ID. 264 is a large number and, as long as it is random, the cookie makes L2TPv3 impervious to brute-force spoofing attacks, where the attacker tries to inject packets into an active session.

After a session is established through the control session, the L2TP endpoint is ready to send and receive data traffic. Although the data header has a Sequence Number field, the data channel is not reliable. The protocol can detect missing, duplicate, or out-of-order packets, but does not retransmit. That is left to higher-layer protocols.

The RFC allows for the data channel to be set up either using the native control protocol, or statically, or using another control mechanism.

In the design sections after Chapter 5, "Infrastructure Segmentation Architectures: Theory," you will see occasions when, frankly, GRE could solve a problem just as well as L2TPv3. What then are the differences between these two protocols? Following is a list of them:

  • Ubiquity—GRE can be found just about everywhere. It is an old (in Internet terms anyway), well-established protocol, and implementations should, by now, be robust. L2TPv3, more recent, is less prevalent.

  • Performance—On high-speed links, especially on enterprise networks, encapsula-tion tax (header length and so forth) is much less of an issue than a couple of decades ago, when trying to wring every last ounce of baud rate from 1200 bps links was an important issue for network administrators the world over. At Gigabit, or 10 Gigabit speeds, the number of bytes used by a well-designed protocol is not really an issue, as long as the implementation runs in hardware. Concerning this last point, it is probably easier to find hardware implementations of GRE than L2TPv3.

  • Payload protocols—RFC 3931 specifically states that L2TPv3 is designed to carry Layer 2 protocols. GRE is a multipurpose solution that can carry any other protocol. However, the devil is in the details, and GRE "implementations" may be limited to specific protocols (such as just Ethernet or IP). Furthermore, L2TPv3 has been extended to carry IP traffic.

  • Cookie—This is the most fundamental difference between the two protocols. GRE has no equivalent of the Cookie field. If this is not important to you—and recall that the main advantage is to provide guarantees against spoofing—implementation issues may dictate your choice more than any difference between the protocols themselves.

L2TPv3 IOS Configuration

There are three things to configure for the L2TPv3 IOS configuration:

  • Control channel parameters

  • Data channel parameters

  • Connection circuit parameters

To configure the first of these parameters, use the l2tp-class command for control channel setup. Here, you can change sequence number settings and so on, but the minimum required is the shared password known to both peers. Example 4-12 demonstrates the use of this command.

Example 4-12 l2tp-class Command

l2tp-class L2WAN
 password 7 00071A150754

As in classic L2TP setup, if you do not give a hostname parameter, the device name is used.

The second part of the configuration is for the data channel. Cisco IOS uses the pseudowire command, which is a generic template also used for Layer 2 over MPLS (called AToM) setup. The pseudowire-class specifies the encapsulation and refers to the control channel setup with the protocol l2tpv3 name command (if you omit this, default control channel settings are used). The pseudowire-class also contains the name of the interface used as the source address of the L2TPv3 packets.

Example 4-13  L2TP pseudowire-class Command

pseudowire-class R103R104
 encapsulation l2tpv3
 protocol l2tpv3 L2WAN
 ip local interface Serial1/0

Figure 4.9

Figure 4-9

L2TPv3 Topology

The final part of the configuration (see Example 14-14) binds the client-facing attachment circuit to the trunk port using the xconnect command (already introduced in the discussion on VPLS earlier in this section). The xconnect command defines the remote peer IP address and a unique virtual circuit (VC) identifier used on each peer to map the L2TPv3 payload to the correct attachment circuit. The L2TPv3 endpoints negotiate unique session and cookie ID values for each VC ID, as shown in Figure 4-9. You must configure a different VC ID for each VLAN, port, or data-link connection identifier (DLCI) transported across an L2TPv3 tunnel (currently, Cisco L2TPv3 supports Ethernet, 802.1q [VLAN], Frame Relay, High-Level Data Link Control [HDLC], and PPP).

Example 4-14 xconnect Command

interface Ethernet0/0
 description Client Facing Port
 no ip address
 no cdp enable
 xconnect 103 encapsulation l2tpv3 pw-class R103R104

It's interesting that although the second and third versions of protocol differ in relatively small ways, the command-line interface (CLI) configuration differs significantly from the standard L2TP access concentrator / L2TP network server (LAC/LNS) configuration that you might have used for dialup or digital subscriber line (DSL) networks. However, there are obvious, and deliberate, similarities with other pseudowire solutions such as Ethernet over MPLS (EoMPLS).

Label Switched Paths

Label switched paths (LSPs) are an interesting hybrid of all the preceding data-path solutions: a Layer 2 data path with Layer 3 control plane. Of course, LSPs are found in MPLS networks, which is a topic that has generated entire library shelves of books and other documents. In this chapter, we present a short review of how packets traverse an MPLS network. We do not cover label distribution or any of the major MPLS applications, such as VPN or traffic engineering (MPLS VPNs are discussed in depth in Chapter 5, however).

What we are going to cover may be summarized as follows:

  • An LSP is a tunnel across an MPLS network made up of individual hop-to-hop segments.

  • MPLS networks uses the IP control plane.

  • LSPs are set up for all known IP prefixes in the IP routing table.

  • LSPs are multiplexed across physical links.

  • Each node in an MPLS network forwards based on fixed-length labels instead of variable-length prefixes.

  • Labels are carried in a shim header, between the Layer 2 and Layer 3 headers.

  • Nodes distribute labels to adjacent nodes using a label distribution protocol.

  • Basic label switching is easy to configure

  • Label switching must be configured on all hops.

1 2 3 4 5 Page 3
Page 3 of 5
SD-WAN buyers guide: Key questions to ask vendors (and yourself)