This topic is to discuss the following lesson:
Rene, do you have IPSEC lesson?
Hi John,
I just published it, it’s a long story:
https://networklessons.com/security/ipsec-internet-protocol-security/
Let me know what you think of it.
Rene
Is the “0” or “7” option relating to whether or not the running-config file saves the key as encrypted or clear text?
Hello Chris
Options 0 and 7 refer to whether or not the key that is sent between the routers during the authentication process is encrypted. In order to encrypt the key in the configuration file, use the system password-encryption
command. This command encrypts authentication key passwords among others.
I hope this has been helpful!
Laz
Hi,
does this means IPsec is the only way to authenticate in OSPFv3?
I tried with the following and it worked:
R2#interface Ethernet0/0
no ip address
ipv6 address 2001::2/64
ospfv3 1 authentication key-chain CISCO
ospfv3 1 ipv6 area 0
R2#show ospfv3 ipv6
OSPFv3 1 address-family ipv6
Router ID 2.2.2.2
Active Key-chains:
Key chain CISCO: Send key 1, Algorithm HMAC-SHA-1, Number of interfaces 1
Area BACKBONE(0)
thanks
Edit: This post gives the idea that OSPFv3 does not support any authentication beside IPsec, but after checking it does support the usual MD5 and HMAC that I mentioned above.
Samer.
Hi,
what about this command? R1(config-if)#ospfv3 encryption ipsec
Hi Samer,
This is interesting, I haven’t seen this before. It seems they added non-IPSec support later in OSPFv3:
https://tools.ietf.org/html/rfc7166
I’ll update the lesson to include this, it’s a valid method to configure authentication.
Rene
Hi Laz,
Does this mean we should be able to capture the key in clear-text, during the ESP exchange , if option 0 is used?
Thanks,
LP
Hi Rene,
The last screenshot seems to be another AH example, not an ESP packet.
BR,
LP
Hello Luis
Whether it’s configured as cleartext or encrypted affects only the way in which it has been saved within the configuration file. If it is cleartext, and you issue the show running-configuration
command, you will be able to read the password. If it is encrypted, then the password in the configuration file itself is replaced with its encrypted form. During the ESP exchange, the key is always exchanged in a secure manner.
I hope this has been helpful!
Laz
Thanks LP, just replaced that screenshot.
Rene
Hi,
Is there an updated lesson containing the other non IPsec authentication methods? I see in the posts above it was in the works…
Br,
Vlad
Hello Vlad,
I just tried this. Here are the configs:
hostname R1
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
key chain OSPF_AUTHENTICATION
key 1
key-string MY_PASSWORD
cryptographic-algorithm hmac-sha-1
!
interface GigabitEthernet0/1
ipv6 enable
ospfv3 1 authentication key-chain OSPF_AUTHENTICATION
ospfv3 1 ipv6 area 0
!
router ospfv3 1
!
address-family ipv6 unicast
router-id 1.1.1.1
exit-address-family
!
end
hostname R2
!
ip cef
ipv6 unicast-routing
ipv6 cef
!
key chain OSPF_AUTHENTICATION
key 1
key-string MY_PASSWORD
cryptographic-algorithm hmac-sha-1
!
interface GigabitEthernet0/1
ipv6 enable
ospfv3 1 authentication key-chain OSPF_AUTHENTICATION
ospfv3 1 ipv6 area 0
!
router ospfv3 1
!
address-family ipv6 unicast
router-id 2.2.2.2
exit-address-family
!
end
When you configure the key-chain, only the hmac-sha options work. You can select MD5 but it won’t work.
The neighbor adjacency works fine:
R1#show ipv6 ospf interface
GigabitEthernet0/1 is up, line protocol is up
Link Local Address FE80::F816:3EFF:FE6D:82A3, Interface ID 3
Area 0, Process ID 1, Instance ID 0, Router ID 1.1.1.1
Network Type BROADCAST, Cost: 1
Cryptographic authentication enabled
Sending SA: Key 1, Algorithm HMAC-SHA-1 - key chain OSPF_AUTHENTICATION
And instead of IPSec, OSPF now uses its own authentication header. You can see it in this capture:
https://www.cloudshark.org/captures/23eea41f6700
Rene
Hi,
I did a packet capture after configuring ESP and it appears the packets are being received on either ends out of order, same behavior I could see in the capture Rene posted. However the communication is happening without issues as I have full adjacency. Just curious, is this the expected behavior?
Hello Philip
Can you specify which packets you see appearing out of order? Can you indicate which ones they are from Rene’s cloudshark capture?
Thanks!
Laz
Hi,
Instead of configuring this 1 by 1 for interfaces would the interface range configuration allow for this or no?
Hello Cameron
Yes, you can apply this using the interface range command. However, if you have a different key for each neighbor, you will still have to issue the commands separately. But remember, that’s only for the configuration of the key. For enabling the authentication for the entire area, you can use the area 0 authentication
command as well, as stated in the lesson.
I hope this has been helpful!
Laz
hello rene, i have a question:
For IPsec Authentication we use Pre-shared Key or PKI ?
For Encryption we use symetric method ( aes or DES, 3Des …) or asymetric we use RSA … ?
For integrity we use SHA or MD5 ?
its correct ?
Hello Houssem
Yes, you are mostly correct. Here’s a bit more detailed explanation:
-
For IPsec Authentication, both PSK and PKI can be used. PSK is simpler and doesn’t require a certificate authority, but it’s less secure and doesn’t scale well. PKI is more secure and scales well, but it’s more complex because it requires a certificate authority.
-
For Encryption, IPsec typically uses symmetric encryption algorithms like AES, DES or 3DES. Asymmetric encryption like RSA is mainly used during the key exchange phase, not for the actual data encryption. This is because symmetric encryption is much faster and more efficient for large amounts of data.
-
For Integrity, both SHA and MD5 can be used. However, MD5 is considered to be less secure than SHA, so it’s generally recommended to use SHA for integrity checking in IPsec.
I hope this has been helpful!
Laz