A virtual private network (VPN) provides a means by which remote computers communicate securely across a public WAN such as the Internet.
A VPN connection can link two LANs (site-to-site VPN) or a remote dial-up user and a LAN. The traffic that flows between these two points passes through shared resources such as routers, switches, and other network equipment that make up the public WAN. To secure VPN communication while passing through the WAN, the two participants create an IP Security (IPsec) tunnel.
Note: The term tunnel does not denote tunnel mode (see Packet Processing in Tunnel Mode). Instead, it refers to the IPsec connection.
IPsec is a suite of related protocols for cryptographically securing communications at the IP Packet Layer. IPsec also provides methods for the manual and automatic negotiation of security associations (SAs) and key distribution, all the attributes for which are gathered in a domain of interpretation (DOI). The IPsec DOI is a document containing definitions for all the security parameters required for the successful negotiation of a VPN tunnel—essentially, all the attributes required for SA and IKE negotiations. See RFC 2407 and RFC 2408 for more information.
This topic includes the following sections:
Security Associations
IPsec Key Management
IPsec Security Protocols
IPsec Tunnel Negotiation
Security Associations
A security association (SA) is a unidirectional agreement between the VPN participants regarding the methods and parameters to use in securing a communication channel. Full bidirectional communication requires at least two SAs, one for each direction. Through the SA, an IPsec tunnel can provide the following security functions:
Privacy (through encryption)
Content integrity (through data authentication)
Sender authentication and—if using certificates—nonrepudiation (through data origin authentication)
The security functions you employ depend on your needs. If you need only to authenticate the IP packet source and content integrity, you can authenticate the packet without applying any encryption. On the other hand, if you are concerned only with preserving privacy, you can encrypt the packet without applying any authentication mechanisms. Optionally, you can both encrypt and authenticate the packet. Most network security designers choose to encrypt, authenticate, and replay-protect their VPN traffic.
An IPsec tunnel consists of a pair of unidirectional SAs—one SA for each direction of the tunnel—that specify the security parameter index (SPI), destination IP address, and security protocol (Authentication Header [AH] or Encapsulating Security Payload [ESP] employed. An SA groups together the following components for securing communications:
Security algorithms and keys.
Protocol mode, either transport or tunnel. Junos OS devices always use tunnel mode. (See Packet Processing in Tunnel Mode.)
Key-management method, either manual key or AutoKey IKE. (See IPsec Key Management.)
SA lifetime.
For inbound traffic, Junos OS looks up the SA by using the following triplet:
Destination IP address.
Security protocol, either AH or ESP. (See IPsec Security Protocols.)
Security parameter index (SPI) value.
For outbound VPN traffic, the policy invokes the SA associated with the VPN tunnel.
IPsec Key Management
The distribution and management of keys are critical to using VPNs successfully. Junos OS supports IPsec technology for creating VPN tunnels with three kinds of key creation mechanisms:
Manual key
AutoKey IKE with a preshared key or a certificate
You can choose your key creation mechanism—also called authentication method—during Phase 1 and Phase 2 proposal configuration. See IPsec Tunnel Negotiation.
This topic includes the following sections:
Manual Key
AutoKey IKE
Diffie-Hellman Exchange
Manual Key
With manual keys, administrators at both ends of a tunnel configure all the security parameters. This is a viable technique for small, static networks where the distribution, maintenance, and tracking of keys are not difficult. However, safely distributing manual-key configurations across great distances poses security issues. Aside from passing the keys face-to-face, you cannot be completely sure that the keys have not been compromised while in transit. Also, whenever you want to change the key, you are faced with the same security issues as when you initially distributed it.
AutoKey IKE
When you need to create and manage numerous tunnels, you need a method that does not require you to configure every element manually. IPsec supports the automated generation and negotiation of keys and security associations using the Internet Key Exchange (IKE) protocol. Junos OS refers to such automated tunnel negotiation as AutoKey IKE and supports AutoKey IKE with preshared keys and AutoKey IKE with certificates.
AutoKey IKE with preshared keys—Using AutoKey IKE with preshared keys to authenticate the participants in an IKE session, each side must configure and securely exchange the preshared key in advance. In this regard, the issue of secure key distribution is the same as that with manual keys. However, once distributed, an autokey, unlike a manual key, can automatically change its keys at predetermined intervals using the IKE protocol. Frequently changing keys greatly improves security, and automatically doing so greatly reduces key-management responsibilities. However, changing keys increases traffic overhead; therefore, changing keys too often can reduce data transmission efficiency.
Note:
A preshared key is a key for both encryption and decryption, which both participants must have before initiating communication.
AutoKey IKE with certificates—When using certificates to authenticate the participants during an AutoKey IKE negotiation, each side generates a public-private key pair and acquires a certificate. As long as the issuing certificate authority (CA) is trusted by both sides, the participants can retrieve the peer’s public key and verify the peer's signature. There is no need to keep track of the keys and SAs; IKE does it automatically.
Diffie-Hellman Exchange
A Diffie-Hellman (DH) exchange allows participants to produce a shared secret value. The strength of the technique is that it allows participants to create the secret value over an unsecured medium without passing the secret value through the wire. The size of the prime modulus used in each group's calculation differs as follows:
DH Group 1—768-bit modulus
DH Group 2—1024-bit modulus
DH Group 5—1536-bit modulus
DH Group 14—2048-bit modulus
DH Group 19—256-bit modulus elliptic curve
DH Group 20—384-bit modulus elliptic curve
DH Group 24—2048-bit modulus with 256-bit prime order subgroup
Note: We do not recommend the use of DH groups 1, 2, and 5.
Because the modulus for each DH group is a different size, the participants must agree to use the same group.
IPsec Security Protocols
IPsec uses two protocols to secure communications at the IP layer:
Authentication Header (AH)—A security protocol for authenticating the source of an IP packet and verifying the integrity of its content
Encapsulating Security Payload (ESP)—A security protocol for encrypting the entire IP packet (and authenticating its content)
You can choose your security protocols—also called authentication and encryption algorithms—during Phase 2 proposal configuration. See IPsec Tunnel Negotiation.
For each VPN tunnel, both AH and ESP tunnel sessions are installed on Services Processing Units (SPUs) and the control plane. Tunnel sessions are updated with the negotiated protocol after negotiation is completed. For SRX5400, SRX5600, and SRX5800 devices, tunnel sessions on anchor SPUs are updated with the negotiated protocol while non-anchor SPUs retain ESP and AH tunnel sessions. ESP and AH tunnel sessions are displayed in the outputs for the show security flow session and show security flow cp-session operational mode commands.
This topic includes the following sections:
AH Protocol
ESP Protocol
AH Protocol
The Authentication Header (AH) protocol provides a means to verify the authenticity and integrity of the content and origin of a packet. You can authenticate the packet by the checksum calculated through a Hash Message Authentication Code (HMAC) using a secret key and either MD5 or SHA hash functions.
Message Digest 5 (MD5)—An algorithm that produces a 128-bit hash (also called a digital signature or message digest) from a message of arbitrary length and a 16-byte key. The resulting hash is used, like a fingerprint of the input, to verify content and source authenticity and integrity.
Secure Hash Algorithm (SHA)—An algorithm that produces a 160-bit hash from a message of arbitrary length and a 20-byte key. It is generally regarded as more secure than MD5 because of the larger hashes it produces. Because the computational processing is done in the ASIC, the performance cost is negligible.
Note: For more information on MD5 hashing algorithms, see RFC 1321 and RFC 2403. For more information on SHA hashing algorithms, see RFC 2404. For more information on HMAC, see RFC 2104.
ESP Protocol
The Encapsulating Security Payload (ESP) protocol provides a means to ensure privacy (encryption) and source authentication and content integrity (authentication). ESP in tunnel mode encapsulates the entire IP packet (header and payload) and then appends a new IP header to the now-encrypted packet. This new IP header contains the destination address needed to route the protected data through the network. (See Packet Processing in Tunnel Mode.)
With ESP, you can both encrypt and authenticate, encrypt only, or authenticate only. For encryption, you can choose one of the following encryption algorithms:
Data Encryption Standard (DES)—A cryptographic block algorithm with a 56-bit key.
Triple DES (3DES)—A more powerful version of DES in which the original DES algorithm is applied in three rounds, using a 168-bit key. DES provides significant performance savings but is considered unacceptable for many classified or sensitive material transfers.
Advanced Encryption Standard (AES)—An encryption standard which offers greater interoperability with other devices. Junos OS supports AES with 128-bit, 192-bit, and 256-bit keys.
For authentication, you can use either MD5 or SHA algorithms.
Note: Even though it is possible to select NULL for encryption, it has been demonstrated that IPsec might be vulnerable to attack under such circumstances. Therefore, we suggest that you choose an encryption algorithm for maximum security.
IPsec Tunnel Negotiation
To establish an AutoKey IKE IPsec tunnel, two phases of negotiation are required:
In Phase 1, the participants establish a secure channel in which to negotiate the IPsec security associations (SAs).
In Phase 2, the participants negotiate the IPsec SAs for encrypting and authenticating the ensuing exchanges of user data.
For a manual key IPsec tunnel, because all the SA parameters have been previously defined, there is no need to negotiate which SAs to use. In essence, the tunnel has already been established. When traffic matches a policy using that manual key tunnel or when a route involves the tunnel, the Juniper Networks device simply encrypts and authenticates the data, as you determined, and forwards it to the destination gateway.
The remote IKE gateway address can be in any virtual routing (VR) instance. VR is determined during IKE Phase 1 and Phase 2 negotiation. VR does not have to be configured in the IKE proposals. If the IKE gateway interface is moved from one VR to another, the existing IKE Phase 1 and Phase 2 negotiations for the IKE gateway are cleared, and new Phase 1 and Phase 2 negotiations are performed.
A VPN connection can link two LANs (site-to-site VPN) or a remote dial-up user and a LAN. The traffic that flows between these two points passes through shared resources such as routers, switches, and other network equipment that make up the public WAN. To secure VPN communication while passing through the WAN, the two participants create an IP Security (IPsec) tunnel.
Note: The term tunnel does not denote tunnel mode (see Packet Processing in Tunnel Mode). Instead, it refers to the IPsec connection.
IPsec is a suite of related protocols for cryptographically securing communications at the IP Packet Layer. IPsec also provides methods for the manual and automatic negotiation of security associations (SAs) and key distribution, all the attributes for which are gathered in a domain of interpretation (DOI). The IPsec DOI is a document containing definitions for all the security parameters required for the successful negotiation of a VPN tunnel—essentially, all the attributes required for SA and IKE negotiations. See RFC 2407 and RFC 2408 for more information.
This topic includes the following sections:
Security Associations
IPsec Key Management
IPsec Security Protocols
IPsec Tunnel Negotiation
Security Associations
A security association (SA) is a unidirectional agreement between the VPN participants regarding the methods and parameters to use in securing a communication channel. Full bidirectional communication requires at least two SAs, one for each direction. Through the SA, an IPsec tunnel can provide the following security functions:
Privacy (through encryption)
Content integrity (through data authentication)
Sender authentication and—if using certificates—nonrepudiation (through data origin authentication)
The security functions you employ depend on your needs. If you need only to authenticate the IP packet source and content integrity, you can authenticate the packet without applying any encryption. On the other hand, if you are concerned only with preserving privacy, you can encrypt the packet without applying any authentication mechanisms. Optionally, you can both encrypt and authenticate the packet. Most network security designers choose to encrypt, authenticate, and replay-protect their VPN traffic.
An IPsec tunnel consists of a pair of unidirectional SAs—one SA for each direction of the tunnel—that specify the security parameter index (SPI), destination IP address, and security protocol (Authentication Header [AH] or Encapsulating Security Payload [ESP] employed. An SA groups together the following components for securing communications:
Security algorithms and keys.
Protocol mode, either transport or tunnel. Junos OS devices always use tunnel mode. (See Packet Processing in Tunnel Mode.)
Key-management method, either manual key or AutoKey IKE. (See IPsec Key Management.)
SA lifetime.
For inbound traffic, Junos OS looks up the SA by using the following triplet:
Destination IP address.
Security protocol, either AH or ESP. (See IPsec Security Protocols.)
Security parameter index (SPI) value.
For outbound VPN traffic, the policy invokes the SA associated with the VPN tunnel.
IPsec Key Management
The distribution and management of keys are critical to using VPNs successfully. Junos OS supports IPsec technology for creating VPN tunnels with three kinds of key creation mechanisms:
Manual key
AutoKey IKE with a preshared key or a certificate
You can choose your key creation mechanism—also called authentication method—during Phase 1 and Phase 2 proposal configuration. See IPsec Tunnel Negotiation.
This topic includes the following sections:
Manual Key
AutoKey IKE
Diffie-Hellman Exchange
Manual Key
With manual keys, administrators at both ends of a tunnel configure all the security parameters. This is a viable technique for small, static networks where the distribution, maintenance, and tracking of keys are not difficult. However, safely distributing manual-key configurations across great distances poses security issues. Aside from passing the keys face-to-face, you cannot be completely sure that the keys have not been compromised while in transit. Also, whenever you want to change the key, you are faced with the same security issues as when you initially distributed it.
AutoKey IKE
When you need to create and manage numerous tunnels, you need a method that does not require you to configure every element manually. IPsec supports the automated generation and negotiation of keys and security associations using the Internet Key Exchange (IKE) protocol. Junos OS refers to such automated tunnel negotiation as AutoKey IKE and supports AutoKey IKE with preshared keys and AutoKey IKE with certificates.
AutoKey IKE with preshared keys—Using AutoKey IKE with preshared keys to authenticate the participants in an IKE session, each side must configure and securely exchange the preshared key in advance. In this regard, the issue of secure key distribution is the same as that with manual keys. However, once distributed, an autokey, unlike a manual key, can automatically change its keys at predetermined intervals using the IKE protocol. Frequently changing keys greatly improves security, and automatically doing so greatly reduces key-management responsibilities. However, changing keys increases traffic overhead; therefore, changing keys too often can reduce data transmission efficiency.
Note:
A preshared key is a key for both encryption and decryption, which both participants must have before initiating communication.
AutoKey IKE with certificates—When using certificates to authenticate the participants during an AutoKey IKE negotiation, each side generates a public-private key pair and acquires a certificate. As long as the issuing certificate authority (CA) is trusted by both sides, the participants can retrieve the peer’s public key and verify the peer's signature. There is no need to keep track of the keys and SAs; IKE does it automatically.
Diffie-Hellman Exchange
A Diffie-Hellman (DH) exchange allows participants to produce a shared secret value. The strength of the technique is that it allows participants to create the secret value over an unsecured medium without passing the secret value through the wire. The size of the prime modulus used in each group's calculation differs as follows:
DH Group 1—768-bit modulus
DH Group 2—1024-bit modulus
DH Group 5—1536-bit modulus
DH Group 14—2048-bit modulus
DH Group 19—256-bit modulus elliptic curve
DH Group 20—384-bit modulus elliptic curve
DH Group 24—2048-bit modulus with 256-bit prime order subgroup
Note: We do not recommend the use of DH groups 1, 2, and 5.
Because the modulus for each DH group is a different size, the participants must agree to use the same group.
IPsec Security Protocols
IPsec uses two protocols to secure communications at the IP layer:
Authentication Header (AH)—A security protocol for authenticating the source of an IP packet and verifying the integrity of its content
Encapsulating Security Payload (ESP)—A security protocol for encrypting the entire IP packet (and authenticating its content)
You can choose your security protocols—also called authentication and encryption algorithms—during Phase 2 proposal configuration. See IPsec Tunnel Negotiation.
For each VPN tunnel, both AH and ESP tunnel sessions are installed on Services Processing Units (SPUs) and the control plane. Tunnel sessions are updated with the negotiated protocol after negotiation is completed. For SRX5400, SRX5600, and SRX5800 devices, tunnel sessions on anchor SPUs are updated with the negotiated protocol while non-anchor SPUs retain ESP and AH tunnel sessions. ESP and AH tunnel sessions are displayed in the outputs for the show security flow session and show security flow cp-session operational mode commands.
This topic includes the following sections:
AH Protocol
ESP Protocol
AH Protocol
The Authentication Header (AH) protocol provides a means to verify the authenticity and integrity of the content and origin of a packet. You can authenticate the packet by the checksum calculated through a Hash Message Authentication Code (HMAC) using a secret key and either MD5 or SHA hash functions.
Message Digest 5 (MD5)—An algorithm that produces a 128-bit hash (also called a digital signature or message digest) from a message of arbitrary length and a 16-byte key. The resulting hash is used, like a fingerprint of the input, to verify content and source authenticity and integrity.
Secure Hash Algorithm (SHA)—An algorithm that produces a 160-bit hash from a message of arbitrary length and a 20-byte key. It is generally regarded as more secure than MD5 because of the larger hashes it produces. Because the computational processing is done in the ASIC, the performance cost is negligible.
Note: For more information on MD5 hashing algorithms, see RFC 1321 and RFC 2403. For more information on SHA hashing algorithms, see RFC 2404. For more information on HMAC, see RFC 2104.
ESP Protocol
The Encapsulating Security Payload (ESP) protocol provides a means to ensure privacy (encryption) and source authentication and content integrity (authentication). ESP in tunnel mode encapsulates the entire IP packet (header and payload) and then appends a new IP header to the now-encrypted packet. This new IP header contains the destination address needed to route the protected data through the network. (See Packet Processing in Tunnel Mode.)
With ESP, you can both encrypt and authenticate, encrypt only, or authenticate only. For encryption, you can choose one of the following encryption algorithms:
Data Encryption Standard (DES)—A cryptographic block algorithm with a 56-bit key.
Triple DES (3DES)—A more powerful version of DES in which the original DES algorithm is applied in three rounds, using a 168-bit key. DES provides significant performance savings but is considered unacceptable for many classified or sensitive material transfers.
Advanced Encryption Standard (AES)—An encryption standard which offers greater interoperability with other devices. Junos OS supports AES with 128-bit, 192-bit, and 256-bit keys.
For authentication, you can use either MD5 or SHA algorithms.
Note: Even though it is possible to select NULL for encryption, it has been demonstrated that IPsec might be vulnerable to attack under such circumstances. Therefore, we suggest that you choose an encryption algorithm for maximum security.
IPsec Tunnel Negotiation
To establish an AutoKey IKE IPsec tunnel, two phases of negotiation are required:
In Phase 1, the participants establish a secure channel in which to negotiate the IPsec security associations (SAs).
In Phase 2, the participants negotiate the IPsec SAs for encrypting and authenticating the ensuing exchanges of user data.
For a manual key IPsec tunnel, because all the SA parameters have been previously defined, there is no need to negotiate which SAs to use. In essence, the tunnel has already been established. When traffic matches a policy using that manual key tunnel or when a route involves the tunnel, the Juniper Networks device simply encrypts and authenticates the data, as you determined, and forwards it to the destination gateway.
The remote IKE gateway address can be in any virtual routing (VR) instance. VR is determined during IKE Phase 1 and Phase 2 negotiation. VR does not have to be configured in the IKE proposals. If the IKE gateway interface is moved from one VR to another, the existing IKE Phase 1 and Phase 2 negotiations for the IKE gateway are cleared, and new Phase 1 and Phase 2 negotiations are performed.
impressive
ReplyDelete