IPsec (Internet Protocol Security)

Hi Laz,

Thank you for the reply.
This confirms some of my thoughts.

So if I use GRE with tunnel protection with tunnel mode, the GRE packet is encapsulated by ESP, and a new header is added.

Since the IPsec uses GRE to communicate, the new header has the same IP address as the tunnel source and destination.

Would you please confirm my thoughts again?

---

As for the link I shared, why the transport mode can not be used in the below topology?

To be honest, I am not sure I understand the explanation in the link.
Would you please explain this in more detail?

image

There is no GRE tunnel between R1 and R2.
I configure the transport mode for IPSec but it still uses tunnel mode.

If I configure the GRE tunnel between R1 and R2, the transport mode can be used.

The following is the configuration of both routers.

R1

crypto isakmp policy 10
 encr aes
 hash sha256
 authentication pre-share
 group 15
crypto isakmp key CISCO address 192.168.1.2    
crypto ipsec transform-set TS esp-aes esp-sha256-hmac 
 mode transport
crypto ipsec profile IPSEC
 set transform-set TS 
crypto map CMAP 10 ipsec-isakmp 
 set peer 192.168.1.2
 set transform-set TS 
 match address ICMP

interface Ethernet0/0
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 crypto map CMAP
end

ip access-list extended ICMP
 permit icmp any any

interface Loopback0
 ip address 1.1.1.1 255.255.255.255
end

R2

crypto isakmp policy 10
 encr aes
 hash sha256
 authentication pre-share
 group 15
crypto isakmp key CISCO address 192.168.1.1  
crypto ipsec transform-set TS esp-aes esp-sha256-hmac 
 mode transport
crypto ipsec profile IPSEC
 set transform-set TS 
crypto map CMAP 10 ipsec-isakmp 
 set peer 192.168.1.1
 set transform-set TS 
 match address ICMP

interface Ethernet0/0
 ip address 192.168.1.2 255.255.255.0
 duplex auto
 crypto map CMAP
end

ip access-list extended ICMP
 permit icmp any any

interface Loopback0
 ip address 2.2.2.2 255.255.255.255
end

show crypto ipsec sa on R1

     inbound esp sas:
      spi: 0x946E41E6(2490253798)
        transform: esp-aes esp-sha256-hmac ,
        in use settings ={Tunnel, }
        conn id: 3, flow_id: SW:3, sibling_flags 80000040, crypto map: CMAP
        sa timing: remaining key lifetime (k/sec): (4179069/1873)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x28C59527(684037415)
        transform: esp-aes esp-sha256-hmac ,
        in use settings ={Tunnel, } 
        conn id: 4, flow_id: SW:4, sibling_flags 80000040, crypto map: CMAP
        sa timing: remaining key lifetime (k/sec): (4179069/1873)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE(ACTIVE)

Thank you

Best regards,
James

Hello James

Yes, that is correct.

When you don’t use GRE, and you use just IPSec, you must have some tunneling mechanism in operation to ensure encapsulation. This is the tunnel mode used.

When you use GRE, tunneling is taken care of, so you are able to use transport mode in IPSec.

It’s a matter of the implementation of the tunnel that is involved.

I hope this has been helpful!

Laz

What is “nonce” shown in the pcap captures in IPSec lessons?

Hello Utpal

A cryptographic nonce is a randomly generated number that can be used only once in a cryptographic communication. The word nonce is a concatenation of “number once”. A nonce is typically used by an authentication protocol to ensure that old communications cannot be reused in replay attacks. They are also used as cryptographic hash functions.

IPSec uses nonces as an authentication method to authenticate a remote peer. Take a look at this Cisco community thread for more information:

I hope this has been helpful!

Laz

Hello,

I just want to get clarification about the function of lifetime during sa negotiation.

In phase 1, we can configure authentication, and DH in the isakmp policy configuration.
Both these use the term key; authentication uses pre-shared key, and DH is used to come with common encryption key.

When lifetime expires, both peers have to renegotiate DH key again. But, authentication remains using the same pre-shared key.

So, main function of lifetime is to force DH renegotiation to generate new encryption key. And this provides better security.

Is my understanding correct?

Hello Mohamad

Yes, your understanding is correct. The preshared keys remain the same, but the SA is deleted once the timer expires, and is renegotiated from scratch. You can find out some more details about this process at the following Cisco documentation:

I hope this has been helpful!

Laz

1 Like

Hi Rene,
Could you share me the link if you managed to write further on NAT traversal.

Thanks

Hello Gopinathan

A lesson on NAT-T has not yet been created, however, I will let Rene know about your request. IN the meantime, take a look at this short NetworkLessons note on how IPSec works with NAT-T… It also includes some additional links that may be useful.

I hope this has been helpful!

Laz

Are there any “accepted” guidelines for which Diffie-Hellman groups to use for VPN tunnels? So far here is what I’m seeing:

“If you are using encryption or authentication algorithms with a 128-bit key, use Diffie-Hellman groups 19, 20. If you are using encryption or authentication algorithms with a 256-bit key or higher, use Diffie-Hellman group 21”

Is this reasonable? What about if you’re using AES-192? Also, is there an “intelligent” way of deciding the best DH group to use depending on what encryption algorithm is in use?

Hello Mike

The Diffie-Hellman group number used determines the strength of the key when used in the key exchange process. Generally speaking, the higher the number, the stronger the key. More information can be found in this NetworkLessons note on Security and the DH groups.

There is no hard and fast rule because there is always a tradeoff between the level of security (and thus the complexity of the algorithms involved) and the computational resources needed. Generally speaking, the higher the number, the more secure you are. One consideration, however, is that anything below a group number of 15 is considered to be insecure for a production environment.

One other thing to keep in mind is that for the Cisco ASA 5500 series models, it is recommended by cisco to enable hardware processing instead of software processing. This is achieved using the crypto engine large-mod-accel command.

I hope this has been helpful!

Laz

Hi,

I have a bunch of questions:

I need some clarification on the Nonce and Key Exchange in captures 1.1.1.3 Message 3 and 1.1.1.4 Message 4. Is the Key Exchange Data in the capture the DH public key of the device that sent the packet?

And for the nonce, how exactly is it used in authentication? Does the recipient of the nonce hash it using the PSK before sending it back as Message 5/6 as a means of authentication? I have read the links in the notes section you your website, plus various other sources, none of which answered my question.

I (think) found the answer to the above question in RFC2049 https://www.rfc-editor.org/rfc/rfc2409:
SKEYID = prf(pre-shared-key, Ni_b | Nr_b)
HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )
So, I’m assuming its all hashed to provide authentication and integrity.

I also read in an earlier question that the DH group generates new keys each time it is created, so, are they randomly generated?

In IKE Phase 2, what keys are used for hashing (authentication)?

And for AH, does the ICV include the data in the AH header for its calculation?

And you mention in a side note that NAT/PAT is an issue with AH, that would also be the case with ESP because the TCP header is encrypted. Is that correct?

Thanks.

Sam

Hello Samir

Yes, the Key Exchange Data within the capture for this IPsec scenario contains the public key of the device that sent the packet. This public key is then used by the receiving device, in combination with its own private key, to derive the shared secret key material. This shared key material is then used to generate encryption and authentication keys for the IKE SA and the subsequent IPsec SAs established during IKE Phase 2.

The nonce is not actually directly used for authentication. Instead, it serves as a cryptographic input to derive keying material, to protect against replay attacks, and to ensure the uniqueness of keying material for each security association. It is used in conjunction with the DH key exchange, however, DH and the nonce serve different purposes in the protocol.

The Diffie-Hellman key exchange is used to establish a shared secret between two parties (initiator and responder) without disclosing it to potential eavesdroppers.

Nonces, on the other hand, are random or pseudo-random numbers generated by each party in the IKE protocol. They serve multiple purposes as described above.

How are these related? In the IKE protocol, both the Diffie-Hellman shared secret and the nonces generated by the initiator and responder are used as input to a key derivation function (KDF), along with other cryptographic parameters. The KDF generates the keying material for the IKE Security Association (SA) and the subsequent IPsec SAs. By using nonces together with the Diffie-Hellman shared secret, the protocol ensures that the derived keying material is unique for each SA, even if the same devices establish multiple SAs.

This level of detail goes beyond the requirements for certification, however, it is useful and interesting to explore.

I hope this has been helpful!

Laz

Hi Laz,

Thanks for responding.

RFC 2409 (section 5) seemed to show that the nonces (Ni/r) are used along with other information to provide authentication and integrity along with the anti-replay protection through hashing, and as you said, for key derivation:

When doing a pre-shared key authentication, Main Mode is defined as follows:

          Initiator                        Responder
         ----------                       -----------
          HDR, SA             -->
                              <--    HDR, SA
          HDR, KE, Ni         -->
                              <--    HDR, KE, Nr
          HDR*, IDii, HASH_I  -->
                              <--    HDR*, IDir, HASH_R

* indicates encryption.

SKEYID = prf(pre-shared-key, Ni_b | Nr_b)

HASH_I = prf(SKEYID, g^xi | g^xr | CKY-I | CKY-R | SAi_b | IDii_b )

SKEYID_d = prf(SKEYID, g^xy | CKY-I | CKY-R | 0)
SKEYID_a = prf(SKEYID, SKEYID_d | g^xy | CKY-I | CKY-R | 1)
SKEYID_e = prf(SKEYID, SKEYID_a | g^xy | CKY-I | CKY-R | 2)

The key used for encryption is derived from SKEYID_e in an algorithm-specific manner.

I’m actually not sure how in-depth to go as I’m studying for the CCIE lab - which you have probably already guessed based on the number of questions I’ve been bombarding you with - but I’ve heard RFCs are something that should be understood. Personally, I find them very difficult to follow and this is as deep as I want to go.

But I still have a couple of higher-level questions:

You mention in a side note that NAT/PAT is an issue with AH, that would also be the case with ESP because the TCP header is encrypted. Is that correct?

And for AH, does the ICV include the data in the AH header for its calculation?

Thanks again for answering all my questions.

Sam

Hello Samir

You are not explicitly required to memorize any specific RFCs or details for the CCIE exam. However, you are given access to some reference materials that may include RFCs as well as Cisco documentation. So you should be familiar with what RFCs are and how to search them to find the information you’re looking for. I don’t believe it is worth going too deep into them. The level of detail you seek here is probably a little beyond what is expected of you, but this is just my personal evaluation.

Actually, ESP resolves this issue with NAT/PAT. This is because ESP provides encryption and authentication, but it does not include the IP header fields that are modified by NAT devices in its authentication calculations.

Yes it does. Take a look at the following section from RFC 4302 which describes this further.

Because the ICV itself is included within the AH header, for the calculation, its value is temporarily set to zero, otherwise, you’d have a circular reference that wouldn’t work…

I hope this has been helpful!

Laz

Hello Rene/Laz,

  1. Does IPsec VPN tunnel support Multicast traffic?
  2. Does IPsec VPN tunnel support any other dynamic routing protocol other than BGP?
  3. Is it mandatory to change the MTU for IPsec VPN tunnel? Where should I change the MTU [a configuration example will be helpful as well]?
  4. Can IKE version 2 be used for Policy-based IPsec VPN tunnel?

Thanks a lot.
Best Regards,
Azm Uddin

Hello Azm

There is a misconception here. The protocol itself has been designed to support multicast, however, this was not a priority in its development. As such, multicast is not commonly used over IPsec VPN tunnels. Most older Cisco devices don’t support it, and thus many believe that it is not supported. But some newer ones do support it using IPsec VTIs. For more info, take a look at this NetworkLessons note that gives more details.

This is a question not of which routing protocol is supported, but what underlying mechanisms needed for dynamic routing protocols are supported. EIGRP, OSPF, and RIP use multicast, so if your IPSec VPN is not set up to use multicast, then they won’t function. IS-IS is a special case since it really operates at Layer 2. If you want to use it over an IPsec VPN you’ll have to ensure that IS-IS messages are encapsulated at layer 2 using L2TPv3 or some other layer 2 encapsulation. Strictly speaking, IS-IS cannot natively be used over an IPsec VPN. BGP doesn’t use multicast, so it is natively supported over IPsec VPNs without any additional configurations needed.

It is not always mandatory to change the MTU for IPsec VPN tunnel, but it’s recommended to avoid fragmentation. IPsec adds overhead to the original packet, and if the MTU is not adjusted, the packet might exceed the MTU size and will require fragmentation. You can change the MTU on the interface which the tunnel is working on.

IKEv2 can be used for both policy-based and route-based IPsec VPN tunnels. However, not all platforms (IOS, ASA, etc) and software versions support it. You’ll have to check the related documentation for your particular device.

I hope this has been helpful!

Laz

Hi Laz,
Throughout my career I have always asked myself these two questions:

  • when to use the AH protocol? (in all configurations I use the ESP) Please give me studies case .
  • can you give me also some studies case where the transport mode is also used?
    So far I really haven’t been able to understand these two points very well in my young career.
    thank you very much for your explanations
    Loac.

Hello loac

When choosing between ESP and AH, you will almost always choose ESP. ESP can almost be thought of as providing a superset of what AH provides. So it delivers the benefits of AH and more. So if you can use ESP, always choose it over AH.

The only advantage that AH has is that it uses fewer resources (CPU, memory, network bandwidth). It would be preferable to use AH only in special cases where data confidentiality is not a requirement and system resources are limited. In the past, when some WAN connections were on the order of several Kb per second, and CPU and memory on network devices were limited, it made sense to use AH. In today’s networks however, with high data capacity and high-performance network equipment, the option to use AH is slowly fading.

So you’re right, unless there is a very specialized use case, it is preferrable to always use ESP over AH.

I hope this has been helpful!

Laz

Hello Laz,
Why is it recommended to avoid fragmentation?

Thanks a lot in advance.

Hello Azm

Fragmentation is a phenomenon that is seen whenever higher-layer encapsulated PDUs do not “fit” within the predefined MTU of lower-layer protocols. There are various situations in which this can occur, and one of them is when using VPNs of various types, including GRE or IPSec or some combination of both.

In general, it is always a good idea to avoid fragmentation. Fragmentation will cause the same amount of data to be transmitted using a greater number of packets, which means more headers, more overhead, and more CPU and memory needed to reassemble data. It may sound trivial, but over time, and with enough fragmentation, it can slow down transmission and use increased amounts of network device resources.

For more information, take a look at this NetworkLessons note on the effects of fragmentation on network traffic.

I hope this has been helpful!

Laz