IPSec Support

The Oracle® Enterprise Session Border Controller offers IPSec for securing signaling, media, and management traffic at the network layer.

Supported Protocols

The Oracle® Enterprise Session Border Controller's IPSec implementation supports all required tools for securing Internet communication via the IPSec protocol suite. The following paragraphs list and explain the protocols within the IPSec suite that the Oracle® Enterprise Session Border Controller supports. This chapter does not explain how to design and choose the best protocols for your application.

AH vs. ESP

The Oracle® Enterprise Session Border Controller supports the two encapsulations that IPSec uses to secure packet flows. Authentication Header (AH) is used to authenticate and validate IP packets. Authentication means that the packet was sent by the source who is assumed to have sent it.

Note:

AH is incompatible with NAT. Validation means that the recipient is assured that the packet has arrived containing the original, unaltered data as sent.

ESP (Encapsulating Security Payload) provides AH's authentication and validations and extends the feature set by ensuring that the IP packet's contents remain confidential as they travel across the network. Using an encryption algorithm that both peers agree upon, ESP encrypts a full IP packet so that if intercepted, an unauthorized party cannot read the IPSec packet's contents.

Tunnel Mode vs. Transport Mode

In addition to its security encapsulations, the IPSec suite supports two modes: tunnel mode and transport mode. Tunnel mode is used most often for connections between gateways, or between a host and a gateway. Tunnel mode creates a VPN-like path between the two gateways and encapsulates the entire original IP packet. Transport mode is used to protect end-to-end communications between two hosts providing a secured IP connection and encrypts just the original payload.

Note:

Traffic sent through the inner IPSec tunnel must be on the same VLAN-slot-port network-interface combination as where the outer tunnel is configured. This is because IPSec tunnel mode does not carry any L2 information for the inner packet. Once the SBC decrypts (de-tunnel) the received packet, it uses the L2 header from the original packet for the lookup. Therefore, if the SBC uses different vlan/slot/port for the inner network, lookups will fail.

Cryptographic Algorithms

IPSec works by using a symmetric key for validation and encryption. Symmetric key algorithms use the same shared secret key for encoding and decoding data on both sides of the IPSec flow. The Oracle® Enterprise Session Border Controller's IPSec feature supports the following encryption algorithms:

  • DES
  • 3DES
  • AES128CBC
  • AES256CBC
  • AES128CTR
  • AES256CTR

The Oracle® Enterprise Session Border Controller can quickly generate keys for all of the above mentioned algorithms from the CLI. It can additionally support HMAC-SHA1 or HMAC-MD5 keyed-hash message authentication codes. Only manual keying is currently supported for both hash authentication and data encryption. Therefore, all keys must be provisioned on the Oracle® Enterprise Session Border Controller by hand.

IPSec Implementation

The Oracle® Enterprise Session Border Controller uses separate logic for processing IPSec packets based on whether the traffic is inbound or outbound. The configuration is divided into two pieces, the security policy and the security association (SA). Both the SA and security policies have a directional attribute which indicates if they can be used and/or reused for inbound and outbound traffic.

Outbound Packet Processing

The following diagrams show the steps the Oracle® Enterprise Session Border Controller follows when processing outbound IPSec traffic. Details of each step are described in the following sections.

Outbound Processing

Security Policy

The Oracle® Enterprise Session Border Controller first performs a policy lookup on outbound traffic to test if it should be subjected to IPSec rules. A security policy, local policy applicable for IPSec functionality, defines the matching criteria for outgoing network traffic to secure. It is configured on a network interface basis.

Configuring a security policy is similar to a local policy, with additional IPSec-specific parameters. Unlike a local policy, used for routing, a security policy is used for packet treatment. As with a local policy, a set of selector values is matched against the outbound flow's following characteristics:

  • VLAN
  • Source IP address (plus mask)
  • Source IP port
  • Destination IP address (plus mask)
  • Destination IP port
  • Transport Protocol

Each of these selection criteria can be defined by a wildcard except for the VLAN ID, which can be ignored. This flexibility aids in creating selection criteria that ranges from highly restrictive to completely permissive. In addition to the main traffic matching criteria, a priority parameter is used to prioritize the order that configured security policies are checked against. The #0 policy is checked first, #1 policy is checked next, continuing to the lowest prioritized policy being checked last.

Once the outbound traffic matches a policy, the Oracle® Enterprise Session Border Controller proceeds to the next step of outbound IPSec processing. If no matching security policy is found, the default pass-through policy allows the packet to be forwarded to the network without any security processing.

Fine-grained policy Selection

After a positive match between outbound traffic and the configured selectors in the security policy, the Oracle® Enterprise Session Border Controller can perform a calculation between a set of fine-grained packet selectors and the outbound packet. The fine-grained policy masking criteria are:

  • Source IP subnet mask
  • Destination IP subnet mask
  • VLAN mask

By default, the fine-grained security policy is set to match and pass all traffic untouched to the security association (SA) portion of IPSec processing.

Fine-grained policy selection works by performing a logical AND between outbound traffic's fine-grained selectors and the traffic's corresponding attributes. The result is then used to find the matching SA. Applying a fine-grained mask has the effect of forcing a contiguous block of IP addresses and/or ports to appear as one address and or port. During the next step of IPSec processing, when an SA is chosen, the Oracle® Enterprise Session Border Controller in effect uses one SA lookup for a series of addresses. Without fine-grained policy selection, unique SAs must always be configured for outbound packets with unique security policy selectors.

Security Associations

After the Oracle® Enterprise Session Border Controller determines that outgoing traffic is subject to IPSec processing, and optionally applies fine-grained masking, an SA lookup is performed on the traffic. An SA is the set of rules that define the association between two endpoints or entities that create the secured communication. To choose an SA, the Oracle® Enterprise Session Border Controller searches for a match against the outgoing traffic's SA selectors. SA selectors are as follows:

  • VLAN
  • Source IP address
  • Source IP port
  • Destination IP address
  • Destination IP port
  • Transport Protocol

If there is a match, the Oracle® Enterprise Session Border Controller secures the flow according to security parameters defined in the SA that the Oracle® Enterprise Session Border Controller chooses. The packet is then forwarded out of the Oracle® Enterprise Session Border Controller. If no match is found, the packets are discarded, and optionally dumped to secured.log if the log-level is set to DEBUG.

Secure Connection Details

Several parameters define an IPSec connection between the Oracle® Enterprise Session Border Controller and a peer. When planning an IPSec deployment, the primary architectural decisions are which IPSec protocol and mode to use. The two choices for IPSec protocol are ESP or AH, and the two choices for IPSec mode are either tunnel or transport. IPSec protocol and mode are both required for an SA configuration. When creating an IPSec tunnel (tunnel mode), the SA must also define the two outside IP addresses of the tunnel.

IPSec tunnel with local and remote IP address

The authentication algorithm and the authentication key must always be configured. The Oracle® Enterprise Session Border Controller supports hmac-md5 or hmac-sha1 authentication algorithms. Because only manual keying is supported, the key must be entered by hand. When encryption is required, the encryption algorithm and the encryption key must be configured. The Oracle® Enterprise Session Border Controller supports des, 3des, aes-128-cbc, aes-256-cbc, aes-128-ctr, and aes-256-ctr encryption algorithms. When using the two encryption protocols that operate in AES counter mode (RFC 3686), an additional nonce value is required. In addition, the security parameter index (SPI) must be configured for each SA. All SPI values mst be unique as well, across all SAs.

Inbound Packet Processing

The following diagram shows the steps the system follows when processing inbound IPSec traffic. Details of each step are described in the following sections.

Inbound Processing

IP Header Inspection

Processing inbound IPSec packets begins by the Oracle® Enterprise Session Border Controller inspecting an inbound IP packet's headers. If the packet is identified as IPSec traffic, as determined by the presence of an AH or ESP header, an SA policy lookup is performed. If the traffic is identified as non-IPSec traffic, as determined by the lack of an IPSec-type (AH or ESP) header, it still is subject to a policy lookup. However, due to the default allow policy, the packet is forwarded directly to the NP, without any security processing.

SA Matching

The Oracle® Enterprise Session Border Controller proceeds to match the inbound IPSec traffic's selectors against configured SAs. Inbound selector masking is performed where noted. These selectors are:

  • VLAN (plus mask)
  • Source IP address (plus mask)
  • Source IP port
  • Destination IP address (plus mask)
  • Destination IP port
  • Transport Protocol
  • SPI

If no matching SA is found, the packets are discarded, and optionally dumped to secured.log if the log-level is set to DEBUG. When the Oracle® Enterprise Session Border Controller finds a matching SA, the packet is authenticated and decrypted according to the configuration and sent to the Oracle® Enterprise Session Border Controller's NP for continued processing.

Inbound Full Policy Lookup

Inbound traffic can optionally be subjected to a full policy lookup, after decryption and authentication. A full policy lookup checks if a security policy exists for this inbound traffic before the Oracle® Enterprise Session Border Controller sends the decrypted packet to the NP. If no matching security policy is found, even after a successful SA match, the packets are discarded, and optionally dumped to secured.log if the log-level is set to DEBUG.

Full policy lookups are useful for traffic filtering. If you wish to drop traffic not sent to a specific port (e.g. drop any traffic not sent to port 5060), a security policy with specific remote-port-match parameter would be used to define what is valid (i.e., not dropped).

HA Considerations

Anti-replay mechanisms, running on IPSec peers, can cause instability with the Oracle® Enterprise Session Border Controllers configured in an HA pair. The anti-replay mechanism ensures that traffic with inconsistent (non-incrementing) sequence numbers is labeled as insecure, assuming it could be part of a replay attack. Under normal circumstances, this signature causes the remote endpoint to drop IPSec traffic.

When a failover occurs between HA peers, the newly-active system starts sending traffic with the IPSec sequence number starting at 0. A remote system's anti-replay mechanism observes this and labels the traffic as insecure. It is therefore recommended that anti-replay protection not be used with Oracle® Enterprise Session Border Controllers in an HA configuration. This situation does not create any problems as long as IPSec peers are not configured to use anti-replay mechanisms.

Packet Size Considerations

The security processor supports receipt of jumbo frames up to 9K (9022 bytes with VLANs, 9018 without). Under normal operation the default outgoing maximum packet size of 1500 bytes is used. This packet size includes the IPSec headers, which will result in less space for packet data (SIP signaling, RTP, etc...).

IPSec Application Example

In this example, the Oracle® Enterprise Session Border Controller terminates an IPSec tunnel. The remote side of the tunnels is a dedicated VPN appliance in the public Internet. Behind that VPN appliance are three non-IPSec VoIP phones. In this scenario, the VPN box maintains the IPSec tunnel through which the phones communicate with the Oracle® Enterprise Session Border Controller.

The IPSec Application Example diagram is described above.

Without the fine-grained option (or alternatively IKE), an SA entry would need to be configured for each of the three phones, communicating over the IPSec tunnel (resulting in 3 tunnels).

This does not scale for manual-keying with a large number of endpoints. Using the fine-grained configuration as well as the inbound SA mask allows any number of endpoints on the 10.1.1.X network to use a single security association (a coarse-grain configuration). The configuration in this example follows:

A packet sent from the Oracle® Enterprise Session Border Controller to any of the phones will match the policy pol1. The remote-ip-mask parameter of the fine-grained configuration will then be masked against the remote-ip, resulting in a SA selector value of 10.1.1.0. This matches security-association sa1, and the packet will be secured and sent over the tunnel. The tunnel-mode addresses in the security-association represent the external, public addresses of the termination points for the IPSec tunnel.

Packets returning from the 10.1.1.0 side of the IPSec tunnel will first match the tunnel-mode local-ip-addr of 218.100.1.1. The packets will then be decrypted using the SA parameters, and the tunneled packet will be checked against the remote-ip-addr field of the SA.

If the fine-grained mask had not been used, three discrete SAs would have to be configured: one for each of the three phones.

ORACLE(manual)# show
        manual
                name                           assoc1
                spi                            1516
                network-interface              lefty:0
                local-ip-addr                  100.20.50.7
                remote-ip-addr                 100.25.56.10
                local-port                     60035
                remote-port                    26555
                trans-protocol                 ALL
                ipsec-protocol                 esp
                direction                      both
                ipsec-mode                     tunnel
                auth-algo                      hmac-md5
                encr-algo                      des
                auth-key
                encr-key
                aes-ctr-nonce                  0
                tunnel-mode
                        local-ip-addr                  100.20.55.1
                        remote-ip-addr                 101.22.54.3
                last-modified-date             2007-04-30 16:04:46

IPSec Configuration

The following example explains how to configure IPSec on your Oracle® Enterprise Session Border Controller.

Note:

If you change the phy-interface slot and port associated with any SAs or SPDs, the Oracle® Enterprise Session Border Controller must be rebooted for the changes to take effect.

Configuring an IPSec Security Policy

To configure an IPSec security policy:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
    ORACLE(configure)#
  2. Type security and press Enter to access the security path of the configuration menu.
    ORACLE(configure)# security
    ORACLE(security)#
  3. Type ipsec and press Enter.
    ORACLE(security)# ipsec
    ORACLE(ipsec)#
  4. Type security-policy and press Enter. The prompt changes to let you know that you can begin configuration.
    ORACLE(ipsec)# security-policy
    ORACLE(security-policy)#
  5. name—Enter a name for this security policy. This parameter is required and has no default.
  6. network-interface—Enter the network interface and VLAN where this security policy applies in the form: interface-name:VLAN
  7. priority—Enter the priority number of this security policy. The default value is zero (0). The valid range is:
    • Minimum—0

    • Maximum—254

  8. action—Enter the action the Oracle® Enterprise Session Border Controller should take when this policy matches outbound IPSec traffic. The default value is ipsec. The valid values are:
    • ipsec—Continue processing as IPSec traffic

    • allow—Forward the traffic without any security processing

    • discard—Discard the traffic

  9. direction—Enter the direction of traffic this security policy can apply to. The default value is both. The valid values are:
    • in—This security policy is valid for inbound traffic

    • out—This security policy is valid for outbound traffic

    • both—This security policy is valid for inbound and outbound traffic

      To define the criteria for matching traffic selectors for this security policy:

  10. local-ip-addr-match—Enter the source IP address to match. The default value is 0.0.0.0.
  11. remote-ip-addr-match—Enter the destination IP address to match. The default value is 0.0.0.0.
  12. local-port-match—Enter the source port to match. A value of 0 disables this selector. The default value is zero (0). The valid range is:
    • Minimum—0

    • Maximum—65535

  13. remote-port-match—Enter the destination port to match. A value of 0 disables this selector. The default value is zero (0). The valid range is:
    • Minimum—0

    • Maximum—65535

  14. trans-protocol-match—Enter the transport protocol to match. The default value is all. The valid values are:
    • UDP | TCP | ICMP | ALL

  15. local-ip-mask—Enter the source IP address mask, in dotted-decimal notation. The default value is 255.255.255.255.
  16. remote-ip-mask—Enter the remote IP address mask, in dotted-decimal notation. The default value is 255.255.255.255.
  17. Save your work using the ACLI done command.

Defining Outbound Fine-Grained SA Matching Criteria

To define outbound fine-grained SA matching criteria:

  1. From within the security policy configuration, type outbound-sa-fine-grained-mask and press Enter. The prompt changes to let you know that you can begin configuration.
  2. local-ip-mask—Enter the fine-grained source IP address mask to apply to outbound IP packets for SA matching. Valid values are in dotted-decimal notation. The default mask matches for all traffic.
  3. remote-ip-mask—Enter the fine-grained destination IP address mask to apply to outbound IP packets for SA matching. Valid values are in dotted-decimal notation. The default mask matches for all traffic.
  4. local-port-mask—Enter the local port mask for this security policy. The default value for this parameter is 0. The valid range is:
    • Minimum—0

    • Maximum—65535

  5. remote-port-mask—Enter the remote port mask for this security policy. The default value for this parameter is 0. The valid range is:
    • Minimum—0

    • Maximum—65535

  6. trans-protocol-mask—Enter the transport protocol mask for this security policy. The default value for this parameter is 0. The valid range is:
    • Minimum—0

    • Maximum—255

  7. vlan-mask—Enter the fine-grained VLAN mask to apply to outbound IP packets for SA matching. The default is 0x000 (disabled). The valid range is:
    • 0x000 - 0xFFF

  8. Save your work using the ACLI done command.

Configuring an IPSec SA

To configure an IPSec SA:

  1. In Superuser mode, type configure terminal and press Enter.
    ORACLE# configure terminal
    ORACLE(configure)#
  2. Type security and press Enter to access the security path of the configuration menu.
    ORACLE(configure)# security
    ORACLE(security)#
  3. Type ipsec and press Enter.
    ORACLE(security)# ipsec
    ORACLE(ipsec)#
  4. Type security-association and press Enter.
    ORACLE(ipsec)# security-association
    ORACLE(security-association)#
  5. Type manual and press Enter. The prompt changes to let you know that you can begin configuration.
    ORACLE(security-association)# manual
    ORACLE(manual)#
  6. name—Enter a name for this security policy.
  7. network-interface—Enter the network interface and VLAN where this security policy applies in the form: interface_name:VLAN
  8. direction—Enter the direction of traffic this security policy can apply to. The default value is both. Valid values are:
    • in | out | both

  9. Save your work using the ACLI done command.

Defining Criteria for Matching Traffic Selectors per SA

To define the criteria for matching traffic selectors for this SA:

  1. From within the manual portion of the security association configuration, you need to set the parameters described in this process.
    ORACLE(security-association)# manual
    ORACLE(manual)#
  2. local-ip-addr—Enter the source IP address to match.
  3. remote-ip-addr—Enter the destination IP address to match.
  4. local-port—Enter the source port to match. A value of 0 disables this selector. The default value is 0, disabling this parameter. The valid range is:
    • Minimum—0

    • Maximum—65535

  5. remote-port—Enter the destination port to match. A value of 0 disables this selector. The default value is 0, disabling this parameter. The valid range is:
    • Minimum—0

    • Maximum—65535

  6. trans-protocol—Enter the transport protocol to match for traffic selectors for this SA. The default value is ALL. The valid values are:
    • UDP | TCP | ICMP | ALL

  7. ipsec-protocol—Select the IPSec protocol to use for this SA configuration. The default value for this parameter is esp. Valid values are:
    • esp | ah

  8. spi—Enter the security parameter index. The default value is 256. The valid range is:
    • Minimum—256

    • Maximum—2302

  9. ipsec-mode—Enter the IPSec mode of this SA. The default value is transport. The valid values are:
    • tunnel | transport

  10. auth-algo—Enter the IPSec authentication algorithm for this SA. The default value is null. The valid values are:
    • hmac-md5 | hmac-sha1 | null

  11. auth-key—Enter the authentication key for the previously chosen authentication algorithm for this SA.

    Note:

    The specified auth-key value will be encrypted in the configuration and will no longer be visible in clear-text.
  12. encr-algo—Enter the IPSec encryption algorithm for this SA. The default value is null. The valid values are:
    • des | 3des | aes-128-cbc | aes-256-cbc | aes-128-ctr | aes-256-ctr | null

  13. encr-key—Enter the encryption key for the previously chosen encryption algorithm for this SA.

    Note:

    The specified encr-key value will be encrypted in the configuration and will no longer be visible in clear-text.
  14. aes-ctr-nonce—Enter the AES nonce if aes-128-ctr or aes-256-ctr were chosen as your encryption algorithm. The default value is 0.

Defining Endpoints for IPSec Tunnel Mode

To define endpoints for IPSec tunnel mode:

  1. From within the manual portion of the security association configuration, you need to set the parameters described in this process.
    ORACLE(security-association)# manual
    ORACLE(manual)#
  2. local-ip-addr—Enter the local public IP address which terminates the IPSec tunnel.
  3. remote-ip-addr—Enter the remote public IP address which terminates the IPSec tunnel.
  4. Save your work using the ACLI done command.

Real-Time IPSec Process Control

The notify secured commands force the IPSec application to perform tasks in real-time, outside of the Oracle® Enterprise Session Border Controller reloading and activating the running configuration. The notify secured usage is as follows:

notify secured [activateconfig | nolog | log | debug | nodebug]

The following arguments perform the listed tasks:

  • nolog—Disables secured logging
  • log—Enables secured logging
  • debug—Sets secured log level to DEBUG
  • nodebug—Sets secured log level to INFO

Key Generation

The generate-key command generates keys for the supported encryption or authentication algorithms supported by the Oracle® Enterprise Session Border Controller's IPSec implementation. The generate-key commands generate random values which are not stored on the Oracle® Enterprise Session Border Controller, but are only displayed on the screen. This command is a convenient function for users who would like to randomly generate encryption and authentication keys. The generate-key usage is as follows:

generate-key [hmac-md5 | hmac-sha1 | aes-128 | aes-256 | des | 3des]