IPSec VPN Components
Internet Key Exchange (IKE): IKE is a protocol defined by RFC 2408 that uses parts of several other protocols, such as Internet Security Association Key Management Protocol (ISAKMP), Oakley, and Secure Key Exchange Mechanism (SKEME), to dynamically create a shared security policy and authenticated keys for services that require keys, such as IPsec.
IKE establishes a secure, authenticated connection whose security relevant parameters will be defined by an IKE SA. This SA is completely distinct from the IPsec SA. The IKE SA is established between two entities and is used to negotiate IPsec SAs.
IKE Provides a framework that provides policy negotiations and key management processes. The reasons to incorporate it into Cisco IPsec VPN technology are:
- Scalability. Without IKE, all IPsec VPN negotiations must be performed manually, on all hosts.
- Manageable manual configuration and SA characteristics negotiation
- Automatic key generation and key refresh
IPsec Negotiation Phases
- IPsec Phase 1: Exchange IKE (or ISAKMP) SA and public value of DH algorithm to establish secure channel for subsequent IKE messages.
- IPsec Phase 2: Exchange IPsec SA used for establishing a secure channel for real traffic. IPsec session keys are derived from the initial keying material that was obtained during the Phase 1 Diffie-Hellman key exchange. The IPsec session keys can be optionally created using new, independent Diffie-Hellman key exchanges by enabling the Perfect Forward Secrecy (PFS) option. This Phase 2 exchange is called the IKE Quick Mode. IKE Quick Mode is one of two modes of IKE Phase 2, with the other being the Group Domain of Interpretation (GDOI) Mode used by GET VPN.
Encapsulating Security Protocol (ESP): IPsec VPN can be work in Transparent mode or Tunnel mode, in which ESP header are inserted in different location of the IP packet subject to IPsec service. ESP provides: Data origin authentication (HMAC); Data integrity (HMAC); Data privacy Prevents replay attack or anti-replay (using Sequence Number).
ESP in Tunnel mode: The whole IP packet including Original IP header is encapsulated as ESP payload with ESP trailer possibly to facilitate encryption. A predefined ESP header is attached to encrypted ESP payload which is in cipher text. Then the whole ESP packet is subject to HMAC and attach the hash value to the trail of ESP packet.
SPI: Security Parameter Index, uniquely identify SA ID
IV: Initialization Vector, block length for block encryption
Next Header: indicate the Header type in encrypted payload, if IP header, then working in Tunnel mode, otherwise, transport mode.
Authentication Data: HMAC output value (Authenticated)
show crypto session
show crypto isakmp sa
show crypto ipsec sa
clear crypto session
clear crypto isakmp