IPsec (Internet Protocol Security)

Lessons Discussion
62

Hello Olvier

You are absolutely correct, thank you for the clarification. The shared key created using DH is used as the symmetric key for encryption, while authentication takes place using a PSK or a digital certificate.

Thanks again!

Laz

63

IKE phase 1 process is used to establish a tunnel that we use for phase 2. Why is phase 2 required; can we not use the results of the phase 1 DH Key exchange - shared secret - to encrypt the communication between peers?

64

Hello Ronald

The purpose of IKE phase 1 is to perform the initial authentication of IPSec peers in a way that will allow all further negotiation procedures (phase 2) to be encrypted. So phase 1 authenticates the peers and creates a secure channel between them to enable secure IKE exchanges. Phase 1 uses a DH exchange to create this secure channel, which in and of itself, does not require the sending of unencrypted passwords, keys, and any other credentials, making it ideal for secure authentication. This is effectively the purpose of DH, to create a secure channel without sending sensitive credentials that are unencrypted over which additional negotiations can occur securely.

Phase 2 is where negotiations take place to configure the IPSec SAs to set up the IPSec tunnel. Here additional SA parameters are set, security associations are established, and an IPSec SA is periodically renegotiated, all taking place securely over the IKE phase 1 tunnel created.

So in short, phase 1 creates a preliminary secure channel using DH in a way where sensitive credentials are not sent in plain text, over which further negotiations of tunnel and security associations are securely exchanged.

I hope this has been helpful!

Laz

1 Like
65

Thanks. Different question now.

AH provides authentication, while ESP additionally offers encryption. What was the reason for AH+ESP in IPSec. Can you offer some applications that you’d use this implementation.

66

Hello Ronald

As mentioned in the lesson, AH offers authentication and integrity but not encryption. In the past ESP at one point did not support authentication, so it was beneficial to implement the two together to ensure a higher level of security. ESP also does not provide integrity protection for packet headers. So, in the past, AH and ESP were often used together to provide both confidentiality and integrity protection for communications. Because authentication capabilities were added to ESP in the second version of IPSec, AH has become less significant. In fact, some IPSec software no longer supports AH. However, AH is still of value because AH can authenticate portions of packets that ESP cannot.

Also keep in mind that using both ESP and AH may be more secure, but may also introduce too much overhead especially for low bandwidth connections. So even though ESP is more popular today than AH, the implementation of either, or both together may still be of benefit depending on the requirements of the implementation.

I hope this has been helpful!

Laz

4 Likes
67

Hi Rene,

I’ve encontered this lesson very difficult to understand.

I can’t read the packets captured, I see the same IP even when the IPSEC is in transport or in the tunnel mode.

68

Instead this configuration I found another way to setup a ipsec tunnel without any acls.

crypto ipsec profile MYPROF
set security-association lifetime seconds 1800
set transform-set TRANS

int tun0
tunnel protection ipsec MYPROF

Instead of

Branch(config)#crypto map MYMAP 10 ipsec-isakmp 
Branch(config-crypto-map)# set peer 192.168.12.1
Branch(config-crypto-map)# set transform-set TRANS 
Branch(config-crypto-map)# match address 100

Does this configuration do the same??

Thank you

69

Hello Giovanni

In the lesson, you can see in tunnel mode that there are two IP headers. In this case, because the two routers are directly connected and use particular IP addresses, both the inside IP header and the outside IP header have the same IP addresses. You can see this in the following wireshark output:

image
image890×676 21.1 KB

But as mentioned in the lesson:

With tunnel mode we add a new IP header on top of the original IP packet. This could be useful when you are using private IP addresses and you need to tunnel your traffic over the Internet.

However, the wireshark output for the transport mode has only one IP header, with the addition of the AH header.

I hope this has been helpful!

Laz

70

Hello again Giovanni

The first setup that you mention in your post uses the IPSec Static Virtual Tunnel Interface. This is a simpler method of configuring a VPN with IPSec without using access lists. This is detailed more fully in the following lesson:


While the second set of commands involves the creation of an IPSec Tunnel Mode Configuration scenario. This is detailed in the following lesson:

Both essentially do the same thing, but the cyrpto ipsec profile command is the newer and preferred method of implementation.

I hope this has been helpful!

Laz

1 Like
71

Thank you.

Another question, I’ve setup a ipsec communication on my gns3 lab.

show crypto ipsec sa

interface: Serial2/3
    Crypto map tag: MYMAP, local addr 192.168.23.3

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
   remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0)
   current_peer 192.168.12.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 7304, #pkts encrypt: 7304, #pkts digest: 7304
    #pkts decaps: 7307, #pkts decrypt: 7307, #pkts verify: 7307
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 192.168.23.3, remote crypto endpt.: 192.168.12.1
     path mtu 1500, ip mtu 1500, ip mtu idb Serial2/3
     current outbound spi: 0x18DE2CB5(417213621)
     PFS (Y/N): N, DH group: none

     inbound esp sas:
      spi: 0x9564A56(156650070)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 41, flow_id: 41, sibling_flags 80000040, crypto map: MYMAP
        sa timing: remaining key lifetime (k/sec): (4238957/3585)

I’m working on the same topology as Renè and i’m tryng to connect to the BRANCH router using telnet.

I can see TELNET traffic on the link, but should it be encrypted right?
I’m expected ESP traffic only.

Schermata%20da%202019-08-22%2016-12-57
Schermata da 2019-08-22 16-12-57.png1920×1080 206 KB

72

Hello Giovanni

Yes, you are correct, the Telnet packet should be encrypted. You mention that you are using the same topology as Rene, however, in this lesson, I only see two routers, and the endpoint IP addresses are in the same subnet. Could you be talking about the topology in a different lesson? Can you check the topology and the configuration and let us know so we can help further?

Thanks!

Laz

73

Hello Rene,
How to convert Aggressive mode to Main mode? Is there any command to check which mode currently exists in the device?

74

Hello Zeman,
by default Main Mode is used, so if you havent configured Aggresive Mode, you are using Main Mode. By default aggresive mode is disabled, following command is there automatically. You can also use “no” in front of following command to eanble aggresive mode.

Router(config)# crypto isakmp aggressive-mode disable

With this command aggressive mode requests to and from a device are blocked. Aggressive mode is not recommended, noone is gonna be killed with 3 more messages from Main Mode.
If you are using IOS then you can see aggresive mode in phase 1 debug, look for something like _AM, which stands for Aggresive Mode.
On ASA you can see it by using.

show crypto isakmp sa

In output:

  • AM stands for Aggresive mode.
  • MM stands for Main Mode.
1 Like
75

Dear all,
I am confused about the following statements on this tutorial. Rene says that the difference between transport and tunnel mode is:
transport => we use the original ip header
tunnel mode => we use a new ip header
But then shortly after he states:
" Tunnel mode is typically used for site-to-site VPNs where we need to encapsulate the original IP packet since these are mostly private IP addresses and can’t be routed on the Internet."

He says that tunnel mode encapsulates the original IP packet, but he just said we use a new ip header… I am confused. Can someone explain?

Thank you.
-G

Update: I looked at Rene’s illustration and I understood. Thanks anyway :slight_smile:

1 Like
76

Hi Guys,

Why doesn’t IPSec support multicast? Is there a technical limitation in how it is implemented?

Thanks,

Gareth.

77

Hello Gareth

The short answer is that the IPsec specification (RFC 2401) simply does not include it. IPsec simply was not designed to support it. But remember that IPSec is not just a single VPN protocol, but a framework composed of a whole suite of protocols. So if you want to you can use a GRE tunnel which does support multicast, and simply encrypt it using IPsec protocols.

I hope this has been helpful!

Laz

1 Like
78

Thanks Laz - thats a useful way of thinking about IPSec. ESP and AH etc. have protocol numbers but IPSec doesn’t because it’s a framework rather than a protocol.

1 Like
79

Hi Lazaros,

So in ike phase 1 we negotiated which DH group we will use to determine the key strength and then generated and shared the keying information in next steps . so the keys which we generated here are used to encrypt the traffic/data(i am not saying userdata)which will be flowing in further steps etc and to be more particular this key will be used in the encryption algorithm which we negotiated at the beginning of establishing ike phase 1.

Also for ike phase 2, 2 peers again negotiate encryption and authentication .I have few doubts here

  1. the encryption algorithm negotiated in phase 2 will be used to encrypt user data and are we using the keys which we created using DH group and then shared in phase 1 ?
  2. Next doubt which i have is that both peers authenticated each other in phase 1 then what are we doing with authentication algorith being negotiated in phase 2?

please correct me wherever I am wrong in understanding.
Thanks

Regards
rs

1 Like
80

Hello Rahul

The encryption algorithm negotiated in phase 1 is only used in the phase 1 (ISAKMP) tunnel. The encryption algorithm used in phase 2 can be different, and is applied to the phase 2 (IPSec) tunnel. This can be seen in the implementation in the following lesson, where AES is used for the phase 1 tunnel, and esp-aes OR esp-sha-hmac encryption parameters are used for the phase 2 tunnel.

In the configuration in the lesson, the keys established in phase 1 are indeed used to apply the encryption in the phase 2 tunnel. This is common practice. These keys are called “keying material” which is a general and fancy term for “secret keys”. The encryption algorithms use these keys to generate the encryption on the data itself. However, IPSec does allow for the creation of new and different keys from those generated in phase 1, for encryption of phase 2 and this is achieved by performing an additional key exchange.

Keep in mind that each tunnel (Phase 1 and Phase 2) contains discrete and independent procedures to allow the tunnels to be established. For phase 1, the authentication which takes place is to establish the phase 1 tunnel. This is achieved using either pre-shared keys or digital certificates.

For phase 2, authentication algorithms available are MD5 or SHA, and must be configured independently of that of the phase 1 tunnel.

I hope this has been helpful!

Laz

2 Likes
81

Hi, I try to understand one thing, AH authenticate the whole IP package but ESP is not, what difference does that make? What does this authentication accomplish?

Thank you,

1 Like