Add_workflow_for_techpubs | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Panel | |
---|---|
In this section:
|
Overview
The
Spacevars | ||
---|---|---|
|
Table 1: IPsec Security Features
IPsec Security Features | Description | ||
---|---|---|---|
IKEv1 or IKEv2 for authentication, keying and security association negotiation |
| ||
IKE algorithms supported |
| ||
ESP encapsulation |
| ||
ESP algorithms supported |
|
Info |
---|
Ping does not work when IPsec is enabled on the IP Interface. |
The Ribbon IP Security (IPsec) feature provides cryptographic protection by the application of IPsec on a packet-by-packet basis controlled by rules in a Security Policy Database (SPD). These rules are applied to each incoming and outgoing packet, and as a function of source IP address, destination IP address, protocol, source port and destination port produce a directive to discard the packet, bypass the packet (allow it to pass as plaintext), or protect the packet with IPsec according to parameters specified in IPsec Protection Profile. IPsec is implemented using Encapsulating Security Payload (ESP) encapsulation.
During IPsec configuration, a single IP SECURITY POLICY instance is created and assigned to the interfaces group. The IP SECURITY POLICY contains the following databases:
Spacevars | ||
---|---|---|
|
Each SPD entry (or rule) identifies local and remote peer transport addresses that apply. This entry also establishes three packet protection actions:
The SPD entry PRECEDENCE establishes that entry's order relative to other entries from 1 to 65535. Each SPD entry references up to three IPsec Protection Profiles that specify an encryption cipher, a maximum time period for maintaining a security association between these peers (the SA "lifetime"), and an anti-replay policy. The three profiles are prioritized from 1 to 3 for use with the SPD entry.
Each IPD entry specifies a remote peer address to use for a protected session. The IPD entry also contains a PRESHARED SECRET (text string), and local and remote identification information. These parameters are all used in the peer-to-peer authentication process. As with SPD entries, IPD entries also reference up to three prioritized IKE Protection Profiles. The IKE profiles specify an encryption cipher, a maximum time period for maintaining security associations, and abandon-session-because-of-error policies. These profiles are also prioritized from 1 to 3 for usage with the IPD entry.
For IPsec Peer configuration details, see Ipsec IPsec - Peer (EMA) or IPsec Peer - CLI.
Info | ||||
---|---|---|---|---|
| ||||
The |
An IPsec SA is the result of a successful two stage negotiation between the
Spacevars | ||
---|---|---|
|
In the IKE phase 1 exchange, the PRESHARED SECRET is used by the peers to authenticate one another. In the IKE phase 2 exchange, the packet selectors, the encryption cipher, the integrity cipher, and the SA lifetime are negotiated. If there is a valid intersection between the peers for all of these parameter values, then the phase 2 negotiation is successful and an IPsec SA will result.
When the negotiation is initiated by the peer, the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
When the
Spacevars | ||
---|---|---|
|
The following table depicts the impact of 'pfsRequired' state to Quick Mode exchange based on the
Spacevars | ||
---|---|---|
|
Table 2: IKEv1 Quick Mode Exchange Results
SBC Role | pfsRequired State | Quick Mode Exchange Action |
---|---|---|
SBC acting as the initiator | Enabled | Quick Mode Exchange includes PFS |
SBC acting as the initiator | Disabled | Quick Mode Exchange does not include PFS |
SBC acting as the responder | Enabled | SBC does not accept Quick Mode Exchange without PFS |
SBC acting as the responder | Disabled | SBC accepts Quick Mode Exchange with or without PFS |
IKEv2 performs mutual authentication between the
Spacevars | ||
---|---|---|
|
Spacevars | ||
---|---|---|
|
All IKE communications consist of pair of messages – a request and a response. The pair is also referred as an exchange. The first exchanges of messages establishing an IKE SA are called the IKE_SA_INIT and IKE_AUTH exchanges; subsequent IKE exchanges are called the CREATE_CHILD_SA or INFORMATIONAL exchanges.
After this exchange, the
Spacevars | ||
---|---|---|
|
The
Spacevars | ||
---|---|---|
|
Once the first two mandatory exchanges have completed in their proper order, all subsequent exchanges can occur in any order as necessary. In the common case, there is a single IKE_SA_INIT exchange and a single IKE_AUTH exchange (a total of four messages) to establish the IKE SA and the first Child SA. In exceptional cases, there may be more than one of each of these exchanges.
The following table depicts the impact of 'pfsRequired' state to CREATE_CHILD_SA Exchange based on
's role during IPSEC SA re-key: Spacevars 0 series4
Table 3: IKEv2 CREATE_CHILD_SA Exchange Results
SBC Role (during IPsec SA Re-key) | pfsRequired State | CREATE_CHILD_SA Exchange Action |
---|---|---|
SBC acting as the initiator of CREATE_CHILD_SA exchange | Enabled | CREATE_CHILD_SA Exchange includes PFS |
SBC acting as the initiator of CREATE_CHILD_SA exchange | Disabled | CREATE_CHILD_SA Exchange does not include PFS |
SBC acting as the responder of CREATE_CHILD_SA exchange | Enabled | SBC does not accept CREATE_CHILD_SA Exchange without PFS |
SBC acting as the responder of CREATE_CHILD_SA exchange | Disabled | SBC accepts CREATE_CHILD_SA Exchange with or without PFS |
Info | ||
---|---|---|
| ||
PFS applies to Quick Mode Exchange for IKEv1, whereas for IKEv2 it applies to SA re-key in CREATE_CHILD_SA Exchange. |
SAs are removable before their lifetime expires using the following methods:
SAs are also removable through notification by the peer that an SA is deleted, or as a result of Dead Peer Detection determining that a peer is unresponsive.
If an SA is deleted by one of the above scenarios within 60 seconds of the time that it was initially established, then as a Denial-of-Service protection the
Spacevars | ||
---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
The table below describes initiator and responder behavior when using different IKE protocols for IPsec Peers:
Table 4: IPsec Peer Initiator and Responder Roles
IPsec Peer | Role | IKE Protocol Version Selected |
---|---|---|
ANY | Initiator | IKEv2 |
Responder | IKEv1 or IKEv2 is selected depending upon the IKE version used by the peer in IKE message. | |
IKEv1 | Initiator | IKEv1 |
Responder | IKEv1. If peer sends IKEv2 message, negotiation is aborted | |
IKEv2 | Initiator | IKEv2 |
Responder | IKEv2. If peer sends IKEv1 message, negotiation is aborted. |