IPsec (Internet Protocol Security)

Lessons Discussion
104

Hi Laz
Thanks for that info, it is very helpful.
I created an object group for the local servers and another for the remote servers and was able to use those objects for the interesting traffic acl.
I then used a vpn filter acl to restrict the traffic between the hosts, for specific ports and protocols, e.g. https and icmp.

My question now is about the static route. The lesson Cisco ASA site to site IEkv2 IPSEC VPN shows adding a static route using the subnets. I have seen other examples where a static route statement was not added for the site to site config.
Do I really need the route statement and what to do if I donā€™t know the remote subnet, just the hosts?

thanks in advance

105

Hello Neil

Great to hear that you got it to work, and thanks for updating us on your progress.

As for your next question, it really depends upon the network topology. The site-to-site tunnel connects two different subnets. When a packet arrives at the E0/0 interface of ASA1 with a destination IP address within the 192.168.2.0/24 subnet, ASA1 must ā€œknowā€ what to do with it. If a dynamic routing protocol like OSPF or EIGRP is configured, then subnets are learned dynamically, and no static routes are necessary. If not, you must configure routing appropriately, and thatā€™s what the static routes are for.

Now if you were to create a Layer 2 tunnel, such as would be the case using L2TP over IPsec on a Cisco ASA, then your subnet would actually span the tunnel. In that case, you wouldnā€™t need to configure routing, since the devices on both ends of the tunnel are on the same subnet! More about how to create an L2TP over IPsec tunnel on a Cisco ASA can be found in this Cisco documentation:

I hope this has been helpful!

Laz

106

Thanks for the various explanations youā€™ve provided for this lesson Laz. They helped to make everything click.

1 Like
107

Hi Rene,

I am a little bit confused about the IP header of transport mode and tunnel mode of ESP.

According to captures in the post, the IP header of both modes is almost the same except for 16 bytes difference I think itā€™s due to the ESP header. (Correct me if I am wrong)

Another question is why the source IP and destination IP are remaining the same.

After searching some information on the Internet, I found this discussion in the Cisco community.

After reading this, I come to some thoughts.

  1. If no GRE tunnel is used, all IPSec connections between two routers are always using tunnel modes even itā€™s configured to use transport mode.
  2. For using IPsec transport mode, GRE is necessary.
  3. GRE with IPSec tunnel mode, the IPsec adds a new header which is the same IP address as the GRE outer header.
    GRE with IPSec transport mode, the IPsec uses the GRE outer header to transport the packet.
    So thatā€™s why source IP and destination IP are the same.

Please correct me if any of them is wrong.

Itā€™s a long post.
Thank you for taking the time to read it.

Best regards,
James

108

Hello James

The difference is the fact that the ESP header in transport mode does not encrypt the IP header:

image
image981Ɨ287 6.55 KB

ā€¦while in tunnel mode, it encapsulates and encrypts the IP header and adds a new IP header to encapsulate the whole thing:
image
image1151Ɨ288 7.96 KB

The fact that the value of the Total Length in the outside IP header is different (152 vs 168 bytes) is simply because the size of the payload is different. In this case the difference is 16 bytes, but it may be different depending on what is contained within the packet itself. Remember the total length includes the size of the header and the payload of the packet.

When using tunnel mode, the source and destination addresses may or may not be the same on the inner and outer IP headers depending on what endpoints are communicating. If you ping from loopback to a loopback, then the inner IP header will have the loopback addresses, and the outer IP header will have the tunnel terminating interface addresses. If you ping from physical interface to physical interface, the IP addresses will be the same on inner and outer IP headers.

In the link you shared, the source and destination IP addresses are those of the loopback interfaces, but the interfaces terminating the tunnel are different. In the example in this lesson, the source and destination are the IP addresses of the tunnel interfaces themselves.

When using GRE, you must use the tunnel option as an inner and an outer IP header are necessary. When not using a tunneling mechanism, you use transport mode, which simply encrypts the payload, and keeps the single IP header for communication.

I hope this has been helpful!

Laz

1 Like
109

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

110

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

112

What is ā€œnonceā€ shown in the pcap captures in IPSec lessons?

113

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

114

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?

115

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
116

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

Thanks

117

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

118

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?

119

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

120

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

121

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

122

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

123

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

124

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