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. |
|
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 ) 3. Use the encrypted communication channel 4. Send IKE identification to authenticate itself |
|
|
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 product 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 ) |
IPsec Modes: | Transport and Tunnel Mode |
Tunnel Mode ( most used ) |
|
Transport Mode | encapsulation of layer 4 of the original packet |
ESP Header | |
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 ) |
...