Versions Compared

Old Version 25

changes.mady.by.user Jean-luc KRIKER

Saved on

compared with

New Version 26

changes.mady.by.user Jean-luc KRIKER

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


https://www.youtube.com/watch?v=15amNny_kKI&t=15s&ab_channel=LearnCantrill

https://www.youtube.com/watch?v=tuDVWQOG0C0&t=240s&ab_channel=PaloAltoNetworksLIVEcommunity


Internet Key Exchange
IKE Version 1 


Phase 1 

The main purpose of Phase 1 is to set up a secure encrypted channel through which the two peers can negotiate Phase 2.



  • Main Mode:  ( site-2-site )
  1. Propose : Asymmetrical Encryption and Authentication Algorithms
  2. Initiator and responder: Diffie-Hellman key exchange process  (send Public key + Random number )

            DH use group 1,2,5,12,19,20,24 for longer/stronger/ number of bit

            Pre-shared key or PSK

            Private Keys ( ???? exchange using PKI or Public key infrastructure with CA ) 

  3. Use the encrypted communication channel

  4. Send IKE identification to authenticate itself

  • Aggressive Mode:  
  1. Initiator Propose : Encryption and Authentication Algorithms  + IKE identity to authenticate itself
  2. Responder Propose
  3. Secure channel for negotiating the IPsec VPN phase 2
Phase 2
Phase 2

The purpose of Phase 2 negotiations is for the two peers to agree on a set of parameters that define what traffic can go through the VPN, and how to encrypt and authenticate the traffic


Generate Symmetrical Encryption Key 

        ESP Encryption Algorithm  ( 3DES/AES )

        AH  Authentication Algorithm ( MD5/SHA1/SHA2)  SH! and MD5 produce a Fixed-length output : a hashed message

        VPN protocol :  ESP(+AH) or AH

        Mode the VPN use:  Tunnel or Transport Mode

IKE Version 2 

https://tools.ietf.org/html/rfc4306

IP / UDP / 500 ( or 4500 if NAT-transversal )



IKE-SA-INIT

IKE-AUTH

CREATE_CHILD_SA

INFORMATIONAL

Bold

IPsec Modes: Transport and Tunnel Mode

Tunnel Mode ( most used )
  • encapsulation of the layer 3 / original packet
  • With ESP(+AH) or just AH



Transport Mode 

encapsulation of layer 4 of the original packet


ESP Header



https://tools.ietf.org/html/rfc4303

PKI or  Public Key Infrastructure

PKI or  Public Key Infrastructure


Large Network

Stronger Auth Security

Exchange of Asymmetrical Keys ( Private and Public )

Private key use to decrypt


RA: Registration Authority

VA: Validation Authority

CA: Certification Authority

Digital certificate: 

Based on X.509

Information:

Issuer / ID

Serial Number

Expiration dates / Validity

Digital signature ( from the Certificate Authority)





Finger Print

File ( or Transaction)  → hashed


hashing

MD5 , SHA1, SHA2

At the source:

                file / text / ....  → hashing Algo  → hashed value / string

On the other side:

            password ( or text ) → same hashing Algo → produce the same hashed value/ string

            compare the two hash

Hash lose information, and can not restore the original information




IKE Identification

IP Address

Hostname

User FQDN

Distinguished name

IKE-ID

SRX VPN Type

Policy-Based VPN

       Policy: from 


Route-Based VPN



 NAT-Transversal

Client is behind a Modem/FW which does NAT/PAT, IKE ( not end-use packet, only negociation messages ) 

Modem/FW using source-NAT → will modify source IP@ and Source TCP/UDP port ( upstream traffic )

Consequence the Hash ( Authenticatation)  is invalid!!!!    

→ Solution:    UDP Encapsulation

Encapsulate and de-capsulate the traffic into UDP/4500  ( instead of IKE negotiation UDP/500 )

...