Page History

 

Overview

The

Spacevars
0 series4

supports secure SIP signaling in peering environments using the IPsec protocol suite as defined in the table below.

Caption
0 Table 1 IPsec Security Features 3 IPsec Security Features

Info
Ping does not work when IPSEC is enabled on the IP Interface.

 

The Sonus 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:

• Security Policy Database (SPD)—An ordered list of "rules" built and configured by operators that specify the type of protection to provide for each packet that is subjected to the rule.
• Internet Key Exchange (IKE) Peer Database (IPD)—A list of peer devices built and configured by operators that defines eligibility and authentication data for protected sessions using IPsec.
• Security Association Database (SAD)—The list of active Security Associations (SAs) created from successful IPsec negotiations between the

  Spacevars
  0 series4

   and protected peers. Each SA is the bundle of algorithms and parameters used to encrypt and authenticate a particular flow in one direction. Thus for normal bidirectional traffic, the flows are secured by a pair of security associations. This list is system rather than operator generated.

Each SPD entry (or rule) identifies local and remote peer transport addresses that apply. This entry also establishes three packet protection actions:

• DISCARD—discard the packet
• BYPASS—pass the packet on without modification
• PROTECT—encrypt the packet according to an encryption algorithm that has been mutually agreed to by the session peers

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 - Peer (EMA) or IPsec Peer - CLI.

Info
title Note
The Spacevars 0 series4 supports Perfect Forward Secrecy (PFS) using the same DH group negotiated for IKE SA establishment.

 

3DES Support

The

Spacevars
0 series4

 supports key length in Triple Data Encryption Standard (3DES). The key length parameter and its value is 8006000c0 (192 decimal). But as per RFC 2407, key length attribute must be removed for the fixed length ciphers. 3DES must be considered as fixed key length cipher for IPsec ESP purpose

.

IKEv1 Negotiation

An IPsec SA is the result of a successful two stage negotiation between the

Spacevars
0 series4

 and a peer. The phase 1 negotiation achieves a (bidirectional) IKE SA. The IKE SA provides a channel over which the two peers carry out a phase 2 negotiation. The successful completion of a phase 2 negotiation achieves an IPsec SA pair (two unidirectional SAs) that the peers may use to protect IP traffic between them until the IPsec SA expires or is removed.

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
0 series4

 behaves as a responder. When SBC initiates the negotiation, it is the active participant in the exchange.
When the

Spacevars
0 series4

 participates as a responder, an initial IKE message from the peer causes

Spacevars
0 series4

 to access the IPD to find an entry enabling the authentication of a session between the peers. After a successful IKE phase 1 negotiation, a subsequent (phase 2) proposal from the peer causes SBC to search the SPD to find an entry with parameter values that overlap those values proposed by the peer. The parameter values in this SPD entry that are common to this entry as well as those proposed by the peer, are offered to the remote peer, as a counter proposal. If the peer accepts this counter proposal, then the IKE phase 2 negotiation is successful and an IPsec SA pair that defines a protection scheme for packets flowing between the SIP peer and SBC is established.

When the

Spacevars
0 series4

 acts as the initiator, an outgoing SIP message from SBC causes the SPD search. The SPD entry that is consequently selected points to a linked IPD entry (identifying the IKE peer) with which to pursue IKE phase 1 and phase 2 negotiations. The successful completion of these negotiations again results in an IPsec SA pair that defines the protection scheme for packets flowing between SBC and the SIP peer.

The following table depicts the impact of 'pfsRequired' state to Quick Mode exchange based on the 

Spacevars
0 series4

's role.

Caption
0 Table 1 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 Support

IKEv2 performs mutual authentication between the

Spacevars
0 series4

 and its peer, and establishes an IKEv2 Security Association (SA) which includes shared secret information used to establish:

1. A set of cryptographic algorithms used by the SAs to protect the traffic between the

   Spacevars
   0 series4

    and the peer
2. CHILD-SAs for Encapsulated Security Payload (ESP) Protocol

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.

• IKE_SA_INIT: This exchange performs the following functions:

• 1. Negotiates cryptographic algorithms for the IKE-SA
  2. Exchanges nonces
  3. Diffie-Hellman exchange

After this exchange, the

Spacevars
0 series4

 and its peer generate the key material used to derive the shared symmetric keys for authentication and encryption. These keys are associated with the IKE_SA which is bi-directional. At this point, the SBC and peer have agreed on cryptographic keys, but they have not authenticated each other. 

• IKE_AUTH: This exchange performs the following functions:

• 1. Exchanges identities
  2. Proves knowledge of the secrets related to those identities
  3. Sets up an SA for the first ESP Child SA (IPsec SA pair)

The

Spacevars
0 series4

 and peer assert their identities (e.g. IP address, fully-qualified domain name) and use pre-shared keys authentication mechanism to prove this assertion. Each peer verifies the other peer’s assertion. Once verified, mutual entity authentication is provided. 

• CREATE_CHILD_SA: This exchange creates new/additional Child SAs and re-keys both IKE SAs and Child SAs.
• INFORMATIONAL: This exchange performs the following functions:
  
  1. Deletes SAs as needed
  2. Reports error conditions
  3. Checks liveliness of the other endpoint

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

Spacevars
0 series4

's role during IPSEC SA re-key:

Caption
0 Table 1 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
title Note
PFS applies to Quick Mode Exchange for IKEv1, whereas for IKEv2 it applies to SA re-key in CREATE_CHILD_SA Exchange.

 

SA Removal

SAs are removable before their lifetime expires using the following methods:

• Globally delete every IKE SA (DELETE...ALL)
• Delete a specific IKE SA by its IKE handle identifier (DELETE...IKE ID...)
• Delete the IPsec SA pair with a given incoming Security Parameter Index value (LOCAL SPI)

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
0 series4

 does not respond to new phase 1 IKE negotiations initiated by that peer for 60 seconds. Otherwise, phase 1 IKE re-negotiations may proceed immediately on a deleted SA.

Anchor
InitiatorResponder InitiatorResponder

Initiator and Responder Behavior

Caption
0 Table 1 IPsec Peer Initiator and Responder Roles 3 IPsec Peer Initiator and Responder Roles
IPsec Peer Protocol Setting 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.

Pagebreak