| Home Prev |  cOS Stream 4.00.03 Administration Guide
|
Next |
|---|
This section looks at the IPsec standards and describes in general terms the various components, techniques and algorithms that are used in IPsec based VPNs.
Internet Protocol Security (IPsec) is a set of protocols defined by the Internet Engineering Task Force (IETF) to provide IP security at the network layer. An IPsec based VPN is made up of two parts:
The first part, IKE, is the initial negotiation phase, where the two VPN endpoints agree on which methods will be used to provide security for the underlying IP traffic. Furthermore, IKE is used to manage connections, by defining a set of Security Associations, SAs, for each connection. SAs are unidirectional, so there are usually at least two for each IPsec connection.
The second part is the actual IP data being transferred, using the encryption and authentication methods agreed upon in the IKE negotiation. This can be accomplished in a number of ways: by using IPsec protocols ESP or AH, or a combination of both. Currently, only ESP is supported in cOS Stream.
The flow of events can be briefly described as follows:
The following sections will describe each of these stages in detail.
This section describes IKE, the Internet Key Exchange protocol, and the parameters that are used with it.
Encrypting and authenticating data is fairly straightforward, the only things needed are encryption and authentication algorithms, and the keys used with them. The Internet Key Exchange (IKE) protocol, IKE, is used as a method of distributing these "session keys", as well as providing a way for the VPN endpoints to agree on how the data should be protected.
IKE has three main tasks:
Security Associations (SAs)
IKE keeps track of connections by assigning a set of Security Associations, SAs, to each connection. An SA describes all parameters associated with a particular connection, such as the IPsec protocol used (ESP/AH/both) as well as the session keys used to encrypt/decrypt and/or authenticate/verify the transmitted data.An SA is unidirectional and relates to traffic flow in one direction only. For the bidirectional traffic that is usually found in a VPN, there is therefore a need for more than one SA per connection. In most cases, where only one of ESP or AH is used, two SAs will be created for each connection, one describing the incoming traffic, and the other describing the outgoing traffic. In cases where ESP and AH are used in conjunction, four SAs will be created.
IKE Proposals
An IKE algorithm proposal list is a suggestion of how to protect IPsec data flows. The VPN device initiating an IPsec connection will send a list of the algorithms combinations it supports for protecting the connection and it is then up to the device at the other end of the connection to say which proposal is acceptable.The responding VPN device, upon receiving the list of supported algorithms, will choose the algorithm combination that best matches its own security policies, and reply by specifying which member of the list it has chosen. If no mutually acceptable proposal can be found, the responder will reply by saying that nothing on the list was acceptable, and possibly also provide a textual explanation for diagnostic purposes.
This negotiation to find a mutually acceptable algorithm combination is done not just to find the best way to protect the IPsec connection but also to find the best way to protect the IKE negotiation itself.
Algorithm proposal lists contain not just the acceptable algorithm combinations for encrypting and authenticating data but also other IKE related parameters. Further details of the IKE negotiation and the other IKE parameters are described next.
IKE Negotiation
An IKE negotiation consists of two phases:IKE Phase-1 - Negotiate how IKE should be protected.
IKE Phase-2 - Negotiate how IPsec should be protected.
These phases are described in detail next.
IKE Phase-1 - IKE Security Negotiation
An IKE negotiation is performed in two phases. The first phase, phase 1, is used to authenticate the two VPN firewalls or VPN Clients to each other, by confirming that the remote device has a matching Pre-Shared Key.Since publishing details of the negotiation in plaintext is undesirable, IKE first agrees upon a way of protecting the majority of the IKE negotiation. This is done by the initiator sending a proposal-list to the responder. After the responder accepts one of the proposals, we try to authenticate the other end of the VPN to make sure it is who we think it is, as well as proving to the remote device that we are who we claim to be. Next, a technique known as a Diffie Hellman Key Exchange is used to initially agree a shared secret between the two parties in the negotiation and to derive keys for encryption.
Authentication can be accomplished through using Pre-shared Keys (PSK) or certificates. Using pre-shared keys is the most common authentication method. Both PSK and certificates based VPNs are supported by cOS Stream.
IKE Phase-2 - IPsec Security Negotiation
In phase 2, another negotiation is performed, detailing the parameters for the IPsec connection.During phase 2 we will also extract new keying material from the Diffie-Hellman key exchange in phase 1 in order to provide session keys to use in protecting the VPN data flow.
If Perfect Forward Secrecy (PFS) is used, a new Diffie-Hellman exchange is performed for each phase 2 negotiation. While this is slower, it makes sure that no keys are dependent on any other previously used keys; no keys are extracted from the same initial keying material. This is to make sure that, in the unlikely event that some key was compromised, no subsequent keys can be derived.
Once the phase 2 negotiation is finished, the VPN connection is established and ready for traffic to pass through it.
IKE Parameters
There are a number of parameters used in the IKE negotiation process and these are summarized below with general explanations.The Local ID is a piece of data representing the identity of the local VPN tunnel endpoint.
These are the subnets or hosts between which IP traffic will be protected by the VPN. In a LAN-to-LAN connection, these will be the network addresses of the respective LANs.
IPsec can be used in two modes, tunnel or transport.
Tunnel mode indicates that the traffic will be tunneled to a remote device, which will decrypt/authenticate the data, extract it from its tunnel and pass it on to its final destination. This way, an eavesdropper will only see encrypted traffic going from one of VPN endpoint to another.
In transport mode, traffic is not tunneled. This mode can be used to secure a connection from a VPN client directly to the Clavister NetShield Firewall, for example for IPsec protected remote configuration.
Currently, cOS Stream only supports tunnel mode.
The remote endpoint (sometimes also referred to as the remote gateway) is the remote device that performs VPN decryption/authentication and that passes the unencrypted data on to its final destination.
The remote endpoint is not used in transport mode.
The IPsec protocols describe how the data will be processed. The two protocols to choose from are AH, Authentication Header, and ESP, Encapsulating Security Payload.
ESP provides encryption, authentication, or both. However, it is not recommended to use encryption only, since it will dramatically decrease security.
Note that AH only provides authentication and does not support encryption. The difference from ESP with authentication only is that AH also authenticates parts of the outer IP header, for instance source and destination addresses, making certain that the packet really came from who the IP header claims it is from.
Since AH protects the outer IP addresses, it not work with NAT.
![[Note]](images/note.png) |
Note |
|---|---|
|
AH is not currently supported by cOS Stream. |
This specifies the encryption algorithm used in the IKE negotiation, and depending on the algorithm, the size of the encryption key used.
This specifies the authentication algorithms used in the IKE negotiation phase.
This specifies the Diffie-Hellman group to use for the IKE exchange. The available DH groups are discussed below in the section titled Diffie-Hellman Groups.
This is the lifetime of the IKE connection.
It is specified in time (seconds). Whenever one of these expires, a new phase-1 exchange will be performed. If no data was transmitted in the last "incarnation" of the IKE connection, no new connection will be made until someone wants to use the VPN connection again. This value must be set greater than the IPsec SA lifetime.
With Perfect Forward Secrecy (PFS) disabled, initial keying material is "created" during the key exchange in phase-1 of the IKE negotiation. In phase-2 of the IKE negotiation, encryption and authentication session keys will be extracted from this initial keying material. By using PFS, completely new keying material will always be created upon rekey. Should one key be compromised, no other key can be derived using that information.
PFS can be used in two modes: the first is PFS on keys, where a new key exchange will be performed in every phase-2 negotiation. The other type is PFS on identities, where the identities are also protected, by deleting the phase-1 SA every time a phase-2 negotiation has been finished, making sure no more than one phase-2 negotiation is encrypted using the same key.
PFS is generally not needed, since it is very unlikely that any encryption or authentication keys will be compromised. It is enabled in cOS Stream by specifying one or more DH groups for the IPsec proposal.
The encryption algorithm that will be used on the protected IPsec traffic.
This is not needed when AH is used, or when ESP is used without encryption.
This specifies the authentication algorithm used on the protected traffic.
This is not used when ESP is used without authentication, although it is not recommended to use ESP without authentication.
This is the lifetime of the VPN connection. It is specified as a time in seconds. Whenever this value is exceeded, a rekey will be initiated, providing new IPsec encryption and authentication session keys. If the VPN connection has not been used during the last rekey period, the connection will be terminated, and re-opened from scratch when the connection is needed again.
This value must be set lower than the IKE lifetime.
Diffie-Hellman Groups
Diffie-Hellman (DH) is a cryptographic protocol that allows two parties that have no prior knowledge of each other to establish a shared secret key over an insecure communications channel through a series of plain text exchanges. Even though the exchanges between the parties might be monitored by a third party, Diffie-Hellman makes it extremely difficult for the third party to determine what the agreed shared secret key is and to decrypt data that is encrypted using the key.Diffie-Hellman is used to establish the shared secret keys for IKE, IPsec and PFS.
The Diffie-Hellman group indicates the degree of security used for DH exchanges. The higher the group number, the greater the security but also the processing overhead. The DH groups supported by cOS Stream are the following:
DH groups are specified in a configuration as part of the IKE proposal list. At least one DH group must be specified in a proposal list. By default, DH groups 5 and 14 are used. The group chosen by the peers during the IKE negotiation will be the highest which both have available. It is recommended to try to use DH group 14 or greater and only use groups less that 14 for compatibility purposes. However, it should be noted that higher DH group numbers require greater processing resources.
IKE and IPsec Lifetimes
Both the IKE and the IPsec connections have limited lifetimes, described in terms of time. These lifetimes prevent a connection from being used for too long, which is undesirable from a security perspective.The IPsec lifetime must be shorter than the IKE lifetime. The difference between the two must be a minimum of 5 minutes. This allows for the IPsec connection to be rekeyed simply by performing another phase-2 negotiation. There is no need to do another phase-1 negotiation until the IKE lifetime has expired.
Default Lifetimes
It default lifetime values are as follows:IKE lifetime - 28800 seconds (8 hours).
IPsec lifetime - 3600 seconds (1 hour).
IKE lifetime - 60 seconds + 5 minutes = 360 seconds.
IPsec lifetime - 60 seconds.
IKE provides a way to securely establish communications between the two ends of an IPsec tunnel. Before examining IKE in detail, the alternative of manually setting up a tunnel is discussed.
Manual Keying without IKE
Without IKE, the "simplest" way of configuring the algorithms used by an IPsec tunnel is by using manual keying. This is a method where the encryption and authentication keys as well as some other parameters are directly configured on both sides of the VPN tunnel.Manual keying is supported by cOS Stream but only for ESP with tunnel mode. However, it has a number of limitations, such as having to always use the same encryption/authentication keys, no anti-replay services. There is also no way of assuring that the remote host/firewall really is the one it says it is.
The vulnerability of manual keying to "replay attacks" means that a malicious entity with access to the encrypted traffic can record packets, store them, and send them to its destination at a later time. The destination VPN endpoint will have no way of telling if this packet is a "replayed" packet or not. Using IKE eliminates this vulnerability.
PSK Based Authentication
Using a Pre-shared Key (PSK) is a method where the endpoints of the VPN "share" a secret key. This is a service provided by IKE, and thus has all the advantages that come with it, making it far more flexible than manual keying.PSK Advantages
Pre-Shared Keying has a lot of advantages over manual keying. These include endpoint authentication, which is what the PSKs are really for. It also includes all the benefits of using IKE. Instead of using a fixed set of encryption keys, session keys will be used for a limited period of time, where after a new set of session keys are used.PSK Disadvantages
One thing that has to be considered when using PSKs is key distribution. How are the PSKs distributed to remote VPN endpoints? This is a major issue, since the security of a PSK system is based on the PSKs being kept secret. Should one PSK be compromised, the configuration will need to be changed to use a new PSK.Certificate Based Authentication
Each VPN firewall has its own certificate, and one or more trusted root certificates.The authentication is based on several things:
That each endpoint has the private key corresponding to the public key found in its certificate, and that nobody else has access to the private key.
That the certificate has been signed by someone that the remote endpoint trusts.
Advantages of Certificates
A key advantage of certificates is added flexibility. Many VPN clients, for instance, can be managed without having the same pre-shared key configured on all of them, which is often the case when using pre-shared keys and roaming clients. Instead, should a client be compromised, the client's certificate can simply be revoked. No need to reconfigure every client.Disadvantages of Certificates
A disadvantage of using certificates is added complexity. Certificate-based authentication may be used as part of a larger public key infrastructure, making all VPN clients and firewalls dependent on third parties. In other words, there are more aspects that have to be configured, and there is more that can go wrong.The IPsec protocols are the protocols used to protect the actual traffic being passed through the VPN. The actual protocols used and the keys used with those protocols are negotiated by IKE.
There are two protocols associated with IPsec, AH and ESP. These are covered in the sections below.
AH (Authentication Header)
AH is a protocol used for authenticating a data stream.AH uses a cryptographic hash function to produce a MAC from the data in the IP packet. This MAC is then transmitted with the packet, allowing the remote endpoint to verify the integrity of the original IP packet, making sure the data has not been tampered with on its way through the Internet. Apart from the IP packet data, AH also authenticates parts of the IP header.
The AH protocol inserts an AH header after the original IP header. In tunnel mode, the AH header is inserted after the outer header, but before the original, inner IP header.
AH is not currently supported by cOS Stream.
ESP (Encapsulating Security Payload)
The ESP protocol inserts an ESP header after the original IP header, in tunnel mode, the ESP header is inserted after the outer header, but before the original, inner IP header.All data after the ESP header is encrypted and/or authenticated. The difference from AH is that ESP also provides encryption of the IP packet whereas AH does not. The authentication phase also differs in that ESP only authenticates the data after the ESP header and the outer IP header is left unprotected.
Since AH protects the outer IP addresses, it cannot be used with NAT.
The ESP protocol is used for both encryption and authentication of the IP packet. It can also be used to do either encryption only, or authentication only.
To agree on the VPN flow parameters, a negotiation between tunnel peers is performed. As a result of these negotiations, the IKE and IPsec security associations (SAs) are established. A proposal list of supported algorithms is the starting point for a negotiation. Each entry in the list defines parameters for a supported algorithm that the VPN tunnel end point device is capable of supporting (the shorter term tunnel endpoint will also be used in this manual). The initial negotiation attempts to agree on a set of algorithms that the devices at either end of the tunnel can both support.
There are two types of proposal lists, IKE proposal lists and IPsec proposal lists. IKE lists are used during IKE Phase-1 (IKE Security Negotiation), while IPsec lists are using during IKE Phase-2 (IPsec Security Negotiation).
Supported Algorithms
The algorithms currently supported by cOS Stream are:Encryption algorithms:
AES128-CBC
AES192-CBC
AES256-CBC
3DES
Null
Data integrity algorithms:
AES-XCBC
SHA-1
SHA-256
SHA-384
SHA-512
MD5
![[Caution]](images/caution.png) |
Caution: SHA1 and MD5 have weaknesses |
|---|---|
|
SHA1 is considered to have weaknesses and should be used with caution. MD5 is no longer considered to be a secure algorithm and should be avoided if possible. |
Pseudo-random function algorithms:
This is the same list as for Data Integrity Algorithms above.
|
Note: AES-XCBC is not available for IKEv1 proposals |
|---|---|
|
The AES-XCBC algorithm cannot be used with IKE proposal lists for IKEv1. If it is accidentally specified, it does not cause an error condition but will be ignored. |
Algorithm Sets
In cOS Stream, the various encryption and integrity algorithms are grouped together into sets according to the level of security they provide. These sets, called High, Low and All, are then used in the predefined IKE and IPsec proposal lists. The sets are as follows:High
This consists of a set of algorithms to give higher security. This is the default algorithm set for an IPsec tunnel if no proposal lists are explicitly set. The complete list is:
3DES and AES256-CBC for encryption.
SHA256, SHA384, SHA512 and AES-XCBC for integrity.
Low
This set gives slightly less security. The complete list is:
3DES and AES128-CBC for encryption.
SHA256 and AES-XCBC for integrity.
All
This set combines all available algorithms.
Creating and Using Proposal Lists
There are two object types that define proposal lists and these make use of the High, Low and All algorithm groupings described above:IKEProposalList
This type has three predefined objects:
ike_high - The IPsec tunnel default.
ike_low
ike_all
IPsecProposalList
This type has three predefined objects:
ipsec_high - The IPsec tunnel default.
ipsec_low
ipsec_all
However, as the example below shows, it is possible to create new custom proposal lists objects with different combinations of algorithms.
Example 13.1. Creating and Using IKE Proposal Lists
This example looks at creating a new IKE proposal list called my_list and adding this to an existing IPsecTunnel object called my_tunnel.
Command-Line Interface
First, create the IKE proposal list:
System:/> add IKEProposalList my_listChange the current context to be the created list:
System:/> cc IKEProposalList my_listAdd at least one proposal to the list:
System:/IKEProposalList/my_list> add IKEProposal DHGroup=2,5
EncryptionAlgorithms=aes128-cbc,aes256-cbc
IntegrityAlgorithms=sha1,md5Return to the original context:
System:/IKEProposalList/ike_list> ccAssociate the proposal list with the tunnel:
System:/> set Interface IPsecTunnel my_tunnel IKEProposalList=my_list
An IPsec proposal list would be created and used in a similar way.
Pre-Shared Keys (PSK) are one of the methods used to authenticate VPN tunnels. The other method is using certificates.
PSKs are secrets that are shared by the communicating parties before communication takes place. To communicate, both parties prove that they know the secret. The security of a shared secret depends on how "good" a passphrase is. Passphrases that are common words are extremely vulnerable to dictionary attacks. A PSK can be specified as either a hexadecimal or ASCII value.
The longer the value used for the PSK, the better the security.
Example 13.2. Adding an ASCII PSK
This example creates a PSK object based on an ASCII string. The object can then be used for authentication with, for example, VPN tunnels
Command-Line Interface
System:/> add PSK my_psk Type=ASCII PSKAscii="mypasswordstring" |
Caution: Non-ASCII characters in PSKs with other platforms |
|---|---|
|
Different encodings on different platforms can cause problems with non-ASCII characters in a non-hexadecimal PSK. For example, Microsoft Windows encodes PSKs containing non-ASCII characters in UTF-16 while cOS Stream uses UTF-8. Even though the same PSK appears to be used at either end of the tunnel, there can be a mismatch because two platforms are encoding differently. As an example, this can cause problems when setting up a Windows L2TP client that connects to cOS Stream. |
Using Certificates Instead of PSKs
The simplest and fastest way to provide security between the ends of an IPsec tunnel is to use Pre-shared Keys (PSKs). However, as a VPN network grows so does the complexity of using PSKs. Certificates provide a means to better manage security in much larger networks.This section deals with specific issues associated with using X.509 certificates with IPsec. For a discussion of certificate uploading and how to define Certificate objects see Section 16.1, Configuring Certificates.
Using the ipsec Certificate Store
It should be noted that when a new Certificate object is created for use with IPsec tunnels, it must be added as a child to the CertificateStore object called ipsec. The ipsec store always exists as a predefined store.Certificates Can be Reused with IPsec
Certificates are global objects that can be reused between IPsec tunnels. Even though a certificate is associated with one tunnel in cOS Stream, it can still be reused with any number of other, different tunnels.Association with IPsec Tunnels
The association between a tunnel and certificates is done by using the LocalID property of the IPsec tunnel and the tunnel's LocalAuthMethod property should be set to Certificate (by default, this also becomes the value for RemoteAuthMethod although the two could be set differently).The LocalID value specified for a tunnel is matched with the Subject or Subject Alternative Name (SAN) fields in the available certificates. If more than one certificate provides a LocalID match, the first matching certificate is used. If wildcard (asterisk) properties match, the closest match is used. The first match will only be used if there are two or more certificates that has the same number of wildcard matches.
An example of a Subject using Distinguished Name (DN) would be:
CN=vpn.example.com,O=Example Ltd,C=SE
It is also possible to view the value to be used by running the following CLI command:
ike -certshow
Wildcards (asterisk) can be used in some of the fields, example:
CN=*.example.com,O=Example Ltd,C=SE
An example of a Subject Alternative Name using an email:
eric@example.com
Or if an FQDN is used:
mydns.example.com
The CRLChecks property of a Certificate object determines if the CRL for the certificate is to be checked by cOS Stream and what happens if the CRL cannot be retrieved in order to do the checking. The possible values for this property are the following:
Enforced
This is the default value and means that the associated CRL must be checked before the certificate can be used for authentication. If the associated CRL cannot be retrieved, perhaps because a CA server is offline, then the certificate will be unusable and authentication will fail.
If the certificate has no CRL associated with it then enforced checking is ignored. A self-signed certificate, such as the ones used for management connections, does not have an associated CRL but will still have this default option selected.
An example of setting this option using the CLI would be:
System:/>cc CertificateStore ipsecSystem:/CertificateStore/ipsec>set Certificate my_cert CRLChecks=Enforced
Conditional
CRL checking will be performed by cOS Stream provided any associated CRL is available. If the CRL cannot be accessed, perhaps because a CA server is offline, then the certificate will be used anyway.
Disabled
The causes all CRL checking to be disabled. The certificate will be used even if there is a CRL associated with it.
CRLs are discussed further in Section 16.2, CA Server Access.
This section looks more closely at IPsec tunnel usage.
An IPsecTunnel object defines an endpoint of an encrypted VPN tunnel. Each IPsec tunnel is interpreted as a logical interface by cOS Stream, with the same filtering and configuration capabilities as an Ethernet interface.
Both IPv4 and IPv6 are supported for both IKE and IPsec. Furthermore, the networks connected together through the tunnel can be IPv4 or IPv6. The IP protocol used for tunnel establishment is independent of the traffic flowing inside the tunnel so that the tunnel might be established using IPv4 but have IPv6 traffic flowing inside it. Similarly, the tunnel might be established with IPv6 but have IPv4 traffic flowing inside it.It is not possible to make the local and remote network for a tunnel a mixture of IPv4 and IPv6 networks. It is also not possible to have dissimilar local and remote endpoints.
Remote Initiation of Tunnel Establishment
When another Clavister NetShield Firewall or another IPsec compliant networking product (also known as the remote endpoint) tries to establish an IPsec VPN tunnel to a local Clavister NetShield Firewall, the list of currently defined IPsec tunnels in the configuration is examined. If a matching tunnel definition is found, that tunnel is opened. The associated IKE and IPsec negotiations then take place, resulting in the tunnel becoming established to the remote endpoint.IP Rules Control Decrypted Traffic
Note that an established IPsec tunnel does not automatically mean that all the traffic flowing from the tunnel is trusted. On the contrary, network traffic that has been decrypted will be checked against the main IP rule set. When doing this IP rule set check, the source interface of the traffic will be the associated IPsec tunnel since tunnels are treated like interfaces in cOS Stream.Returning Traffic
For network traffic going in the opposite direction, back into an IPsec tunnel, a reverse process takes place. First, the unencrypted traffic is evaluated by the rule set. If a rule and route matches, cOS Stream tries to find an established IPsec tunnel that matches the criteria. If not found, cOS Stream will try to establish a new tunnel to the remote endpoint specified by a matching IPsec tunnel definition.IPsec Tunnels Themselves Do Not Require IP Rules
By default, all traffic entering and leaving an IPsec tunnel is subject to defined IP rules so those must be defined in the rule sets for traffic to flow inside the tunnel.However, the IPsec tunnel itself does not need any IP rules defined. These rules are hidden, and created automatically by cOS Stream so that IKE negotiations and tunnel establishment can take place.
Dead Peer Detection
After establishment of an IPsec tunnel to a client, cOS Stream uses an Informational message sent through the tunnel to the client as a Dead Peer Detection (DPD) mechanism. This message contains an empty encrypted payload.If the client does not respond, six further DPD messages are sent by cOS Stream at progressively longer intervals before DPD is triggered, the client is considered unreachable and the tunnel's SAs are torn down. DPD is unidirectional, being concerned only with incoming tunnel traffic.
The interval that cOS Stream waits, when no traffic is received, before triggering DPD message sending, is determined by the IPsecTunnel property IKEDPDInterval. This has a default value of 90 seconds and this is the recommended setting for most scenarios. If this is set to zero, DPD will be disabled.
The value of IKEDPDInterval can be set as low as 10 seconds but the number of tunnels that cOS Stream can check in a short interval is limited. For this reason, it is recommended that the IKEDPDInterval value should not be less than 60 seconds, especially in environments with large numbers of IPsec tunnels.
IPsec Connection Using Two IPsec Tunnel Objects
As discussed in Section 13.6, IPsec Troubleshooting, a potential problem can occur when a single IPsec VPN tunnel is set up referencing two IPsec tunnel objects. This can cause confusion for the administrator so further explanation can be helpful.Consider the situation of an IPsec client sending a request to open a tunnel to cOS Stream. The client begins by sending an IKE_INIT request that includes a proposal list, key information and a notification payload. cOS Stream then scans the list of IPsec tunnel objects looking for the closest match and uses the tunnel object it finds.
However, the tunnel chosen may not be the "right" tunnel since not all information needed for a correct match is yet available to cOS Stream. In the next IKE_AUTH stage of the setup process, the client sends the remainder of the required information and this may result in cOS Stream needing to find another IPsec tunnel object for the connection.
An example of this is two tunnels A and B with the following characteristics:
Tunnel A has:
AES-128 in its proposal list.
Authentication with PSK using ID id_a@somecompany.com
A remote endpoint of all-nets-ip4.
Tunnel B has:
3DES in its proposal list.
Authentication with certificates using ID id_b@somecompany.com.
A remote endpoint of 177.22.0.47.
Now, consider the following sequence:
A client with IPv4 address 177.22.0.47 initiates an IPsec negotiation with an IKE_INIT message.
Assuming that the client's proposal list can match either tunnel, the IPsec tunnel object B is chosen for the connection because its remote endpoint is a narrower match to the client's IP address.
The IKE_AUTH phase now begins and cOS Stream finds out that the client wants to use PSK for authentication with an ID of id_a@somecompany.com.
Tunnel B no longer matches the client's authentication requirements. cOS Stream will therefore search the IPsec tunnel object list looking for another tunnel that can match and finds tunnel definition A.
The end result of these steps is that an IPsec tunnel is established but it uses the IKA SA established with tunnel B and the authentication established with tunnel A. This may not be the intended result so the administrator should take care when defining IPsec tunnel objects.
The Clavister NetShield Firewall supports IPsec rekeying. This means that a rekey of the IKE and IPsec Security Associations (SAs) will be initiated based upon the configured values in the proposal lists for IKE and IPsec. The lifetimes of the IKA SAs and IPsec SAs can be limited based on the time since they were created.cOS Stream will respond to rekeying requests initiated by the MS as described by the IKEv2 specification.
![[Important]](images/important.png) |
IPsec Configuration Changes |
|---|---|
|
The administrator should be aware of the effect of uploading a new configuration to a Clavister NetShield Firewall that is supporting live IPsec tunnels. If any changes to the IPsec configuration are made as part of a new configuration, then any live IPsec tunnel connections will be terminated and must be reestablished. |
This next section covers the steps for IPsec tunnel setup with cOS Stream in more detail.
The Clavister NetShield Firewall provides the option to use manually keyed IPsec tunnels. This is done by using the IPsecManualKeyedTunnel object instead of the IPsecTunnel object.
The difference with a manually keyed tunnel is that the IKE phase of the tunnel setup is completely missing. This means that there is no proposal list involved and the integrity and encryption algorithms to use are specified manually along with other tunnel parameters.
Manually keyed tunnels are not normally used in a live production environment because the security is lower than a normal IPsec tunnel. However, they are often useful for testing purposes. Another advantage is that they provide extremely fast tunnel establishment times since the IKE phase is removed and the IKE processing overhead is absent.
Setting Up Manually Keyed Tunnels
To set up a manually keyed tunnel:Add an IPsecManualKeyedTunnel to the configuration. This object is used as an interface in exactly the same way as an IPsecTunnel object and has exactly the same base properties such as LocalNetwork, RemoteNetwork, LocalEndpoint and RemoteEndpoint.
Add an ESP object as a child of the IPsecManualKeyedTunnel object. It is this ESP object which is used to statically define the algorithms and keys that will be used and it takes the place of the IKE negotiation.
Specifying the ESP Object
Only one ESP object needs to be added to a tunnel object. Multiple objects are allowed to support future tunnel features.An ESP object represents the end result of an IKE negotiation had it taken place, and the assigned ESP object properties must match the parameters set for the remote end of the tunnel. In addition, an SPI (Security Parameter Index) value must be specified for both the incoming and outgoing traffic. The SPI value is inserted into traffic so that the different flow can be distinguished from each other.
The SPI values selected must match the values specified at the remote end of the tunnel, with the incoming SPI value for one end being the same as the outgoing SPI value at the other end. The SPI values must also be unique within the configuration. That is to say, two IPsecManualKeyedTunnel objects cannot share the same SPI value within the same configuration.
Example 13.3. Creating a Manually Keyed IPsec Tunnel
In the example, a manually keyed tunnel called mkt1 is created. It is assumed that the address book objects and PSK objects have already been created.
Command-Line Interface
First, create the IPsecManualKeyedTunnel object:
System:/> add Interface IPsecManualKeyedTunnel mkt1
LocalNetwork=mkt1_local_net
LocalEndpoint=mkt1_local_ip
RemoteNetwork=mkt1_rem_net
RemoteEndpoint=mkt1_rem_ipNext, change the CLI context to be this IPsecManualKeyedTunnel:
System:/> cc Interface IPsecManualKeyedTunnel mkt1Now, add the ESP object as a child:
System:/IPsecManualKeyedTunnel/mkt1> add ESP
Encryption=3des
EncryptionKeyIn=mkt1_ekey_in
EncryptionKeyOut=mkt1_ekey_in
Integrity=md5
IntegrityKeyIn=mkt1_ikey_in
IntegrityKeyIOut=mkt1_ikey_in
SPIIn=1
SPIOut=2Finally, return to the default CLI context:
System:/> cc
