Hello Friends, this is part 1 of this ikev2 series. This was focused on ike_sa_init. But since it became huge in size, so decided to make 2nd part for ike_auth , create child sa etc. kindly share your feedback on this deep dive session
@@the-confused-engineeryou are creating tye video having good content. So we are waiting if you can come with any course. Are you IT professional and working in mnc? Most of people are confused with security and how tunnel works.
Yeah buddy, I am a senior Tech Lead working in an MNC. I will take this as a suggestion and start working on it. Whichever topics you need videos on please comment here. I will prepare content on them
37:48 Nonce exchanged + DH shared secret or Nonce exchanged + DH public key? In the video, you mentioned both public key and shared secret. On 37:52 as you mentioned "Jo shared secret bheja geya tha". A shared secret never leaves the device. Right? Could you clear up this confusion?
Skeyseed is calculated using nonce exchanged + DH shared secret. Actually, DH formula works in such a way that it's not shared , but still it can be calculated at both ends using defined parameters. So, don't be confused, it is never shared but calculated. Yes, DH public key is sent to other party, as it is one of the components which helps in creating shared secret.
before ike_init_sa establishment is there any intigrity maintailnace, or security handler are there. my question is ,are the packets are protected before ike_init_sa establishment, or at the time of first negotiation
Ike sa init is the initial exchange wherein there is no protection or integrity or security handler provided. So, it goes normally but yes DOS attack prevention is provided to prevent spoofing attacks. For this, responder sends a cookie along with the Ike sa init packet, for which the initiator will have to respond with the cookie itself. Packets are encrypted and integrity protected only after this initial part is done, but not before Ike sa init. And later once Ike auth is completed, then they are authenticated as well.
15:44 As mentioned here, two keys are going but exactly one key is there. Others are just supported DH groups (might be key generated from it, I am not sure) are going. Isn't it?
Two keys are there public and private but only public is sent to the other side. Private key is never shared. The second part of other supported DH groups is a different entity altogether, but is shared as an option, just in case, the main key is not accepted, then there should be a backup, instead of getting straight rejection.
Hi Pavan, PFS and SRF are entirely different and they serve totally different purposes, so please don’t be confused in them. PFS is meant for extra security in ipsec if enabled. PFS guarantees that the encryption keys for IPsec SA negotiations are created separately for each negotiation. While SRF (Service routing function) has nothing to do with SA negotiation or security. it is just used for MPLS labelling in order to route the traffic further as per MPLS routing rules. The Service Routing Function (SRF) inspects inner (traffic) packet meta-data and selects possible MPLS label stacks based on it. The packet is encrypted, headers are added (including outer IP) and IPSec policies are applied (e.g. selection of child SA) Encrypted (IPSec) packets are handed over for further processing (MPLS label application), which is a function of packet characteristics and IPSec policy, after which it is routed according to MPLS routing rules.
Hi Pari, apologies for the delay, but since no one requested for Ikev1 video so I also didn't paid attention to it. But since you have requested now, I will start working on it. Thanks for your support 🙏
Hello Friends, this is part 1 of this ikev2 series. This was focused on ike_sa_init. But since it became huge in size, so decided to make 2nd part for ike_auth , create child sa etc. kindly share your feedback on this deep dive session
Thank you for making these videos, the concept is well explained, hope to see more content from you.
Thank you so much buddy ☺️ .
Gr8 content. Are you planning to publish any course??
Thanks Sourabh for your appreciation ☺️
That's actually a good idea. Never thought in that direction and don't have any idea how to do it 😜
@@the-confused-engineeryou are creating tye video having good content. So we are waiting if you can come with any course. Are you IT professional and working in mnc? Most of people are confused with security and how tunnel works.
Yeah buddy, I am a senior Tech Lead working in an MNC. I will take this as a suggestion and start working on it. Whichever topics you need videos on please comment here. I will prepare content on them
Explanation is very good. Can you suggest any documentation to follow?
Thank you 😊. I would suggest to devote some time in online communities like Cisco live, Palo Alto community etc , along with Google search.
37:48 Nonce exchanged + DH shared secret or Nonce exchanged + DH public key? In the video, you mentioned both public key and shared secret. On 37:52 as you mentioned "Jo shared secret bheja geya tha". A shared secret never leaves the device. Right? Could you clear up this confusion?
Skeyseed is calculated using nonce exchanged + DH shared secret. Actually, DH formula works in such a way that it's not shared , but still it can be calculated at both ends using defined parameters. So, don't be confused, it is never shared but calculated. Yes, DH public key is sent to other party, as it is one of the components which helps in creating shared secret.
before ike_init_sa establishment is there any intigrity maintailnace, or security handler are there.
my question is ,are the packets are protected before ike_init_sa establishment, or at the time of first negotiation
Ike sa init is the initial exchange wherein there is no protection or integrity or security handler provided. So, it goes normally but yes DOS attack prevention is provided to prevent spoofing attacks. For this, responder sends a cookie along with the Ike sa init packet, for which the initiator will have to respond with the cookie itself. Packets are encrypted and integrity protected only after this initial part is done, but not before Ike sa init. And later once Ike auth is completed, then they are authenticated as well.
15:44 As mentioned here, two keys are going but exactly one key is there. Others are just supported DH groups (might be key generated from it, I am not sure) are going. Isn't it?
Two keys are there public and private but only public is sent to the other side. Private key is never shared. The second part of other supported DH groups is a different entity altogether, but is shared as an option, just in case, the main key is not accepted, then there should be a backup, instead of getting straight rejection.
❤❤❤ nice bro
Thank you so much for your appreciation 😊
Hello, sir what is the difference between SRF and PFS both are the same? or different.
Hi Pavan,
PFS and SRF are entirely different and they serve totally different purposes, so please don’t be confused in them.
PFS is meant for extra security in ipsec if enabled.
PFS guarantees that the encryption keys for IPsec SA negotiations are created separately for each negotiation.
While SRF (Service routing function) has nothing to do with SA negotiation or security.
it is just used for MPLS labelling in order to route the traffic further as per MPLS routing rules.
The Service Routing Function (SRF) inspects inner (traffic) packet meta-data and selects possible MPLS label stacks based on it.
The packet is encrypted, headers are added (including outer IP) and IPSec policies are applied (e.g. selection of child SA)
Encrypted (IPSec) packets are handed over for further processing (MPLS label application), which is a function of packet characteristics and IPSec policy, after which it is routed according to MPLS routing rules.
good
Thank you 😊
Thanks
You are most welcome 🤗
Where is the deep dive video of IKEv1?
It will be released in sometime. Thanks for your support
@@the-confused-engineer first we need to understand IKEv1 then move to IKEv2
Agreed buddy, will make videos on ikev1 soon
Sir where is video of IKEV1
Hi Pari, apologies for the delay, but since no one requested for Ikev1 video so I also didn't paid attention to it. But since you have requested now, I will start working on it. Thanks for your support 🙏
ua-cam.com/video/nQ4WJrIPh7E/v-deo.html&pp=iAQB
It's finally releasing this week. Thanks for your patience and support 🙏