Taking a short detour from STP, I'm devoting a few posts for IPsec VPNs. I had to do IPsec VPN troubleshooting for a customer, and since the topic is included in the CCIE Routing and Switching blueprint, I figured it would be a good time to refresh my memory on the subject. So hang on tight, the posts are going to be long..
Overview
The term
VPN, which stands for Virtual Private Network, is a broad category for
providing private connectivity between devices operating over a shared
infrastructure (like VLANs, MPLS, or GRE tunnels). However, it does not directly
imply encryption and security. This is what IPsec is for. IPsec implements
cryptographic protocols, and provides three basic benefits:
- authentication: using pre-shared keys or digital certificates to verify the source
- confidentiality: encrypting data before transmission, and hence, preventing data from being captured
- integrity: ensuring that data has not been tampered with by an attacker
In short,
deploying an IPsec VPN is a cost-effective method to secure data transmission
over insecure shared media. IPsec VPN tunnels are typically implemented, when a
growing organization expands to multiple locations, and secure connectivity is
required between the sites.
Negotiating The Tunnel
Before two
peers can establish a secure communications tunnel, they must negotiate a
number of parameters. This negotiation process consists of two phases: IKE
Phase 1 and IKE Phase 2. Phase 1 sets up a bidirectional control/management
tunnel by mutually authenticating peers, negotiating cryptographic parameters,
and creating session keys. The Phase 1
tunnel, also referred to as IKE/ISAKMP SA, has only one purpose: to securely carry
out the negotiation for the IPsec tunnels, which are established in Phase 2. Phase 2
is entirely dependent on the completion of Phase 1. Phase 2 builds two one-way IPsec tunnels (IPsec
SAs), which are used for actual user data transmission.
IKE Phase 1
The
following attributes are negotiated in IKE Phase 1 to establish the IKE SA
(Security Association):
- encryption algorithm: a symmetric algorithm used to encrypt the traffic (DES, 3DES, AES)
- authentication method: the procedure to verify the identity of the peer (pre-shared keys or PKI)
- hashing algorithm: a mechanism to produce a checksum that allows peers to detect if data has been modified during transit (MD5, SHA)
- Diffie-Hellman group: a process that enables peers to securely exchange a shared secret, which is then used by the symmetric encryption algorithm to encrypt data; Diffie-Hellman group determines the strength of the key used by the process (DH-1, DH-2, DH-5 etc.)
The aforementioned attributes are mandatory, and must be explicitly defined in a security policy (also called an ISAKMP policy). In addition, a lifetime for the SA is specified either as a function of seconds or bits transmitted (the peers agree on the lower value). Multiple security policies can be configured.
The IKE SA negotiation can be performed in one of two modes: main mode or aggressive
mode.
The following describes, how Main mode
uses three pairs of messages to negotiate the IKE SA (added sanitized packet captures):
1. The initiator
sends its configured security policies to the responder. They are sequentially
evaluated until a policy, which contains parameters that both peers agree on,
is found.
a. Message #1 from the Initiator.
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1),
Dst: 10.0.0.2 (10.0.0.2)
User Datagram Protocol, Src Port: isakmp (500), Dst
Port: isakmp (500)
Internet Security Association and Key Management
Protocol
Initiator SPI:
cf02326f14a95b93
Responder SPI:
0000000000000000
Exchange type: Identity Protection (Main Mode) (2)
Type Payload: Security Association (1)
Type Payload: Transform (3) # 1
Transform ID:
KEY_IKE (1)
Transform IKE
Attribute Type (t=1,l=2) Encryption-Algorithm : AES-CBC
Transform IKE
Attribute Type (t=14,l=2) Key-Length : 128
Transform IKE
Attribute Type (t=2,l=2) Hash-Algorithm : SHA
Transform IKE
Attribute Type (t=4,l=2) Group-Description : Default 768-bit MODP group
Transform IKE
Attribute Type (t=3,l=2) Authentication-Method : PSK
Transform IKE
Attribute Type (t=11,l=2) Life-Type : Seconds
Transform IKE
Attribute Type (t=12,l=4) Life-Duration : 86400
b. Message number #2 from the Responder.
Internet Protocol Version 4, Src: 10.0.0.2 (10.0.0.2),
Dst: 10.0.0.1 (10.0.0.1)
User Datagram Protocol, Src Port: isakmp (500), Dst
Port: isakmp (500)
Internet Security Association and Key Management
Protocol
Initiator SPI:
cf02326f14a95b93
Responder SPI:
18a109f89219e8df
Exchange type: Identity Protection (Main Mode) (2)
Type Payload: Security Association (1)
Type Payload: Transform (3) # 1
Transform ID:
KEY_IKE (1)
Transform IKE
Attribute Type (t=1,l=2) Encryption-Algorithm : AES-CBC
Transform IKE
Attribute Type (t=14,l=2) Key-Length : 128
Transform IKE
Attribute Type (t=2,l=2) Hash-Algorithm : SHA
Transform IKE
Attribute Type (t=4,l=2) Group-Description : Default 768-bit MODP group
Transform IKE
Attribute Type (t=3,l=2) Authentication-Method : PSK
Transform IKE
Attribute Type (t=11,l=2) Life-Type : Seconds
Transform IKE
Attribute Type (t=12,l=4) Life-Duration : 86400
2. The
Diffie-Hellman key exchange to establish a “shared secret” is performed.
The
Diffie-Hellman key exchange allows both peers to independently produce the same
key for encrypting and decrypting data. I will not go into the details of the
underlying cryptographic algorithm, which involves large prime numbers, but
below is a simplified illustration of the Diffie-Hellman key exchange concept.
In simplicity, the idea is to agree to use a common prime number, then “mix” it with a secret integer, and send the product to the peer. The peer will then add its own secret integer into the product, which results in an identical key that is computationally difficult, if not impossible, for modern computers to reverse in a reasonable amount of time. The peers have jointly established a shared secret key over an insecure communications channel.
a. Message #3 from the Initiator.
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1),
Dst: 10.0.0.2 (10.0.0.2)
User Datagram Protocol, Src Port: isakmp (500), Dst
Port: isakmp (500)
Internet Security Association and Key Management
Protocol
Initiator SPI:
cf02326f14a95b93
Responder SPI:
18a109f89219e8df
Type Payload: Key Exchange (4)
Next payload:
Nonce (10)
Key Exchange
Data: 3bce03faae189d2b151a4d527d6122a23b87fb1344d4084b...
Type Payload: Nonce (10)
Nonce DATA:
6ea7c7ed3ca3383538801b4b32a5aba161807765
b. Message #4 from the Responder.
Internet Protocol Version 4, Src: 10.0.0.2 (10.0.0.2),
Dst: 10.0.0.1 (10.0.0.1)
User Datagram Protocol, Src Port: isakmp (500), Dst
Port: isakmp (500)
Internet Security Association and Key Management
Protocol
Initiator SPI: cf02326f14a95b93
Responder SPI: 18a109f89219e8df
Type Payload: Key Exchange (4)
Next payload:
Nonce (10)
Key Exchange
Data: babc863ab198bd0c0c94a5c79eb31579948fcdc79cb31656...
Type Payload: Nonce (10)
Nonce DATA:
781a7f836ed8f1231b779d24ca0a366cad029684
3. The
session is authenticated. The peers validate their identities by using
pre-shared keys or digital certificates. At this point, the communication is
encrypted.
a. Message #5 from the Initiator.
Internet Protocol Version 4, Src: 10.0.0.1 (10.0.0.1),
Dst: 10.0.0.2 (10.0.0.2)
User Datagram Protocol, Src Port: isakmp (500), Dst
Port: isakmp (500)
Internet Security Association and Key Management
Protocol
Initiator SPI:
cf02326f14a95b93
Responder SPI:
18a109f89219e8df
Next payload: Identification (5)
Exchange type: Identity Protection (Main Mode) (2)
Encrypted
Data (80 bytes)
b. Message #6 from the Responder.
Internet Protocol Version 4, Src: 10.0.0.2 (10.0.0.2),
Dst: 10.0.0.1 (10.0.0.1)
User Datagram Protocol, Src Port: isakmp (500), Dst
Port: isakmp (500)
Internet Security Association and Key Management
Protocol
Initiator SPI:
cf02326f14a95b93
Responder SPI:
18a109f89219e8df
Next payload: Identification (5)
Exchange type: Identity Protection (Main Mode) (2)
Encrypted
Data (48 bytes)
The graph
below is a visual representation of the IKE Phase 1 Main Mode.
Contrary to the six messages (three pairs) exchanged in Main Mode, Aggressive
Mode uses only three messages. The same information is still exchanged between the peers,
but the process is abbreviated to the following steps:
1. The
initiator sends ISAKMP policies, Diffie-Hellman details, and identity
information to the responder. The first packet is basically equivalent to the
first four packets in Main Mode.
2. The
responder authenticates the packet and sends back its key material, and an
identification hash.
3. The
initiator verifies the identity of the responder from the hash. If it matches,
Phase 1 is completed and IKE SA is established.
NOTE: when
using Aggressive Mode, the authentication information is exchanged between
peers unencrypted. This means that if an attacker is able to catch Phase 1
messages, the identification information can be gathered, providing an
opportunity to exploit systems.
IKE Phase 2
After IKE
Phase 1 has successfully completed, the peers move on to IKE Phase 2, whose
purpose is to establish the actual IPsec connection that will be used to
securely forward application data later. Unlike the bidirectional IKE SA, the
IPsec SAs are unidirectional. The IPsec SAs are created through Quick Mode. The
communication consists of three messages, and is encrypted by the algorithm
specified in the IKE SA.
By default,
the shared secret exchanged in IKE SA negotiation is also used for the IPsec
SAs. However, during Quick Mode, the peers may enable Perfect Forward Secrecy
(PFS), which causes a new shared secret to be created through another
Diffie-Hellman key exchange for each IPsec SA. PFS adds overhead, but it also
provides greater security.
The
following steps briefly describe the operation of Quick Mode:
1. The
initiator sends its transform-sets to the responder. The associated information
includes the encryption algorithm, the hash algorithm for integrity checking,
the tunnel encapsulation type (ESP or AH), the tunnel mode (tunnel or
transport), the proxy IDs to define “interesting traffic”, and Diffie-Hellman
group if PFS is used.
2. The
responder exams the proxy IDs, and compares them to the proxy IDs defined on
itself. The proxy IDs must match (mirrored) or a failure occurs. The responder
returns the acceptable transform-set to the initiator.
3. The last message of the negotiation operates as a type of keepalive verification mechanism, which has two purposes: 1) to verify that the initiator received and processed the message that the responder sent in the in the previous step, and 2) to avoid DoS replay attacks on the responder by resending the first messages (the negotiation is tracked by a message ID).
After the last message is received, all negotiations have concluded, and the peers are ready to exchange encrypted traffic. Finally, one bidirectional IKE SA and unidirectional IPsec SAs (inbound and outbound) will have formed.
Modes of Operation
As briefly
mentioned earlier, there are two modes of operation: Tunnel Mode and Transport
Mode. The essential difference is that Transport Mode protects only the data
contained in the IP packet payload (the original source and destination
information is retained), whereas Tunnel Mode protects the entire IP datagram
by adding a new IP header (containing the IP addresses of the VPN gateways).
Security Protocols
There are
two security protocols, which define the encapsulation type of IPsec traffic:
ESP (Encapsulation Security Payload) and AH (Authentication Header). AH
provides only integrity checking and origin authenticity. In addition to these
features, ESP also provides confidentiality (encryption). Because of the lack
of encryption in AH, ESP is often preferred.
The graph
below depicts the packet structure of AH and ESP in Transport Mode and Tunnel
Mode, respectively.
“Interesting Traffic”
The proxy
IDs, which are exchanged in IKE Phase 2, refer to the “interesting traffic” that
triggers the whole process of negotiating the IKE/IPsec SAs and defines what
type of traffic is encrypted. As an example, the proxy ID will contain the
following information:
- local proxy ID (source): 10.1.1.0/24
- remote proxy ID (destination): 192.168.1.0/24
- service: any
The configured
proxy IDs (mirrored) must match between the peers for IKE Phase 2 to complete
successfully. Reflecting on the previous example, the peer must have the
following configuration:
- local proxy ID (source): 192.168.1.0/24
- remote proxy ID (destination): 10.1.1.0/24
- service: any
No comments:
Post a Comment