3. IPSec tunnel

3.1. Configuration

We'll create an IPSec tunnel between R1 and R3. This means that we will no longer see the 10.128.x.x traffic on R2, if everything goes as planned.

The Internet Key Exchange must be enabled first on the routers R1 and R3. Remember that with Cisco, there is no real distinction between ISAKMP and IKE.

(config)#crypto isakmp enable

So, next we'll take the following steps:

  • Establish an ISAKMP policy
  • Configure pre-shared keys
  • Configure the IPsec transform set
  • Define interesting traffic
  • Apply the crypto map to interfaces

For both routers, we use the following ISAKMP policy:

enable
 config t
  crypto isakmp policy 10
  hash sha
  authentication pre-share
  group 14
  lifetime 3600
  encryption aes 256
 end

crypto isakmp policy 10 creates a policy with a priority of 10. 1 is the highest priority, and 10 seems to be a more or less standard priority. As a hashing agorithm, we'll use SHA. That means SHA-1, which is not considered fit for use in the outside world. But this is only a demo environment. We'll use pre-shared keys for the initial set-up. group 14 means 2048-bit Diffie-Hellman group. And the rest is easy to understand.

The set-up is easy to verify:

R1# show crypto isakmp policy
Global IKE policy
Protection suite of priority 10
        encryption algorithm:  AES - Advanced Encryption Standard (256 bit keys).
        hash algorithm:        Secure Hash Standard
        authentication method: Pre-Shared Key
        Diffie-Hellman group:  #14 (2048 bit)
        lifetime:              3600 seconds, no volume limit

The next step is to configure the pre-shared keys. IRL, you would not use test123 as key, ofcourse. Both sides must have the same key. For R1, that would be:

 crypto isakmp key test123 address 192.168.200.1

and for R3:

 crypto isakmp key test123 address 192.168.201.1

Next is the transform set. A transform is a single IPSec security protocol (either AH or ESP) with its corresponding security algorithms and mode.

The AH (Authentication Header) is mainly used for authentication. In addition, AH provides data integrity, data origin authentication, and an optional replay protection service. Data integrity is ensured by using a message digest that is generated by an algorithm such as HMAC-SHA that we use here. Data origin authentication is ensured by using a shared secret key to create the message digest. Replay protection is provided by using a sequence number field with the AH header. AH authenticates IP headers and their payloads, with the exception of certain header fields that can be legitimately changed in transit, such as the Time To Live (TTL) field.

The ESP (Encapsulating Security Payload) protocol provides data confidentiality (encryption) and authentication (data integrity, data origin authentication, and replay protection). ESP can be used with confidentiality only, authentication only, or both confidentiality and authentication. When ESP provides authentication functions, it uses the same algorithms as AH, but the coverage is different. AH-style authentication authenticates the entire IP packet, including the outer IP header, while the ESP authentication mechanism authenticates only the IP datagram portion of the IP packet.

Either protocol can be used alone to protect an IP packet, or both protocols can be applied together to the same IP packet

We'll use ESP in this case. We define the transform set on both routers with:

crypto ipsec transform-set 50 esp-aes 256 esp-sha-hmac

Next step: define interesting traffic, that is, what traffic should go through the tunnel. Whenever Cisco defines something about traffic, it is always done with an ACL. So here too, we'll create an ACL. For R1:

 access-list 101 permit ip 10.128.11.0 0.0.0.255 10.128.12.0 0.0.0.255

and for R3:

 access-list 101 permit ip 10.128.12.0 0.0.0.255 10.128.11.0 0.0.0.255

A crypto map is a configuration entity that combines:

  • Selection data flows that need security processing.
  • Definition the policy for these flows and the crypto peer to which that traffic needs to go.

We define it as follows (for R1):

 crypto map CMAP 10 ipsec-isakmp
 match address 101
 set peer 192.168.200.1
 set pfs group14
 set transform-set 50
 set security-association lifetime seconds 900

The CMAP is the name of the crypto map and 10 its sequence number. The ipsec-isakmp is the type for this crypto map. The selection of the addresses is done with the ACL that we defined (101). The peer is R3.

PFS, or Perfect Forward Security, ensures will force a new key every set-up, and a Diffie-Hellman key exchange.

group
bits
algortithm
Remarks
1
768-bit
DH
No longer recommended
2
1024-bit
DH
No longer recommended
5
1536-bit
DH
No longer recommended
14
2048-bit
DH
15
3072-bit
DH
16
4096-bit
DH
19
256-bit
elliptic curve DH (ECDH)
20
384-bit
ECDH
24
2048-bit
DH/DSA

The transform-set is defined previously. The lifetime is, at this point quite arbitrary.

And finaly, we apply the crypto map to the outgoing interface of the router:

 int f0/0
 crypto map CMAP

For R3, the only difference is the set peer 192.168.201.1 (R1 is the peer here).

3.2. Analysis

And after a ping fron xenial1 to xenial2, the tunnel is up before we can fire-up wireshark. Which is good, but does not allow us to examine what is happening. So we just reload R3 (be sure to wr to save the configuration!). After some OSPF packets, we see the ISAKMP:

ws_isakmp.xcf

We'll try to match that with the protocol as we know it from text books:

ike_main_flow.dia

Our first packet contains ISAKMP headers and the SA proposal. It is an UDPs 500 packet from R3 (the initiator) to R2.

Frame 159: 206 bytes on wire (1648 bits), 206 bytes captured (1648 bits) on interface 0
Ethernet II, Src: ca:02:52:6d:00:08 (ca:02:52:6d:00:08), Dst: ca:01:52:6d:00:06 (ca:01:52:6d:00:06)
Internet Protocol Version 4, Src: 192.168.200.1, Dst: 192.168.201.1
User Datagram Protocol, Src Port: 500 (500), Dst Port: 500 (500)
    Source Port: 500
    Destination Port: 500
    Length: 172
    Checksum: 0x8da5 [validation disabled]
    [Stream index: 0]

The protocol is ISAKMP. To focus on specific lines, I've removed some lines that are less interesting at this point.

Internet Security Association and Key Management Protocol
    Initiator SPI: 9e8a87000c6619ff
    Responder SPI: 0000000000000000
    Next payload: Security Association (1)
	<...>
    Type Payload: Proposal (2) # 1
	<...>
        Proposal transforms: 1
            Type Payload: Transform (3) # 1
            Next payload: NONE / No Next Payload  (0)
            Payload length: 36
            Transform number: 1
            Transform ID: KEY_IKE (1)
            Transform IKE Attribute Type (t=1,l=2) Encryption-Algorithm : AES-CBC
            Transform IKE Attribute Type (t=14,l=2) Key-Length : 256
            Transform IKE Attribute Type (t=2,l=2) Hash-Algorithm : SHA
            Transform IKE Attribute Type (t=4,l=2) Group-Description : 2048 bit MODP group
            Transform IKE Attribute Type (t=3,l=2) Authentication-Method : PSK
            Transform IKE Attribute Type (t=11,l=2) Life-Type : Seconds
            Transform IKE Attribute Type (t=12,l=2) Life-Duration : 3600
            Type Payload: Vendor ID (13) : RFC 3947 Negotiation of NAT-Traversal in the IKE
    Next payload: Vendor ID (13)
    <...>

Here we see the result of our IOS configs:

crypto isakmp policy 10
hash sha
Hash-Algorithm : SHA
authentication pre-share
Authentication-Method : PSK
group 14
Group-Description : 2048 bit MODP group
lifetime 3600
Life-Duration : 3600
encryption aes 256
Encryption-Algorithm : AES-CBC Key-Length : 256

Frame 160, the reply to this, has basically the same information.

Next, in packets 161 and 162, we see a nonce being exchanged, and the remainder of the packets just contain encrypted data.

After the ISAKMP, there are a number of ESP packets. These are all encrypted, so it is impossible to see from the network waht is in those packets.