White Lists for Managing Incoming SIP Headers and Parameters
By default, the Oracle Communications Session Border Controller (OCSBC) ignores unknown SIP headers and URI parameters and passes them through. If you require the OCSBC to accept only messages with headers and URI parameters complying with those supported by your internal equipment, you can use white lists to control unknown headers and parameters in request and response traffic. A white list is an approved list of entities for which your equipment provides particular privileges, access, and recognition. The OCSBC uses configured white list profiles to control and accept specific inbound SIP headers and URI parameters. When you configure this service, the OCSBC rejects requests not matching the configured profile, or removes the headers or URI parameters not specified in the configured profile.
White lists allow you to specify which SIP signaling messages you want to allow into your network and which messages to reject or delete. In the flow of SIP traffic to and from the OCSBC, the OCSBC matches any received request or response against the white list and rejects or deletes elements that do not match based on the actions specified in the white list configuration.
For responses, the OCSBC does not reject the message if a header or parameter is not found in the white list, even if the action is set to reject. Instead, the OCSBC deletes the offending parameter or header. In addition, if the message is a request of the method type ACK, PRACK, CANCEL or BYE, the OCSBC deletes all unmatched elements and does not reject the request, even if the action was configured to reject.
The white list verification performs for any method, but you can narrow the list to operate only on specific methods by defining them in the methods parameter of the configuration.
White list verification occurs when the OCSBC receives a request or response, but only after the OCSBC processes the inbound header manipulation rule (HMR), network management controls (NMC), Resource-Priority header (RPH), and monthly minutes checking.
The OCSBC responds to requests that with non-matching headers or parameters configured with an action of reject with a "403 Forbidden" response, by default. You can use a local-response event, allowed-elements-profile-rejection, to override the default reject status code and reason phrase.
The configured white list operates transparently on headers that contain multiple URIs or multiple header values within a single header (header values separated by a comma).
Parameter parsing operates only on parameters that it can identify. For parameters that cannot be parsed, for example an invalid URI (<sip:user@host.com&hp=val>), the OCSBC ignores this URI header parameter value of "hp" because it is not contained within a valid URI. Even though it might look like a URI header parameter, URI headers must come after URI parameters. Parameter matching does not occur if the headers and parameters in the URI are not well-formed. The OCSBC does not remove the parameter just because it cannot identify it.
What is a Whitelist
A whitelist is an approved list of entities for which equipment provides particular privileges, access, and recognition. The Oracle Communications Session Border Controller can use configured whitelist profiles to control and accept specific inbound SIP headers and URI parameters that are being passed-through the Oracle Communications Session Border Controller. When you configure this feature, the Oracle Communications Session Border Controller rejects requests not matching the configured profile, or removes the unspecified headers or URI parameters not in the configured profile.
Configure White Lists for SIP Header and URI Parameter Management
You can configure white list profiles that tell the Oracle Communications Session Border Controller (OCSBC) to accept only inbound SIP headers and URI parameters that are configured in this white list. Using the allowed-elements-profile parameter, you can configure the settings for this parameter using the ACLI interface at session-router, enforcement-profile. Because the enforcement-profile object also pertains to session agents, realms, and SIP interfaces, you can also apply the enforcement profiles you configure to these entities, as well. (Use the ACLI interface at session-router, session-agent, session-router, sip-interface, and media-manager, realm-config.)
The following configuration example assumes that your baseline configuration passes SIP traffic, with the OCSBC in the role of an Access SBC. Use this procedure to configure a white list for the session router and optionally apply the specific white lists to the session agent and SIP interface, as well as the media manager realm configuration.
Configuration Exception
In certain circumstances, the Oracle Communications Session Border Controller (OCSBC) ignores specific parameters in incoming Request-URI messages and automatically adds header-rules.
In a Request-URI, all parameters are URI parameters and URI headers are not allowed. If you define values for the “allow-header-param”, “allow-uri-header-name”, and “allow-uri-param”, the OCSBC ignores these parameters in the Request-URI. Instead, the OCSBC automatically adds header-rules for incoming “Via”, “From”, To”, “Call-ID”, and “CSeq” messages. These are explicit header rules that you cannot delete. Each header-rule in a Request-URI includes parameters populated with the value of *. If required, you can change the header-rule parameter values with the values identified in the following table.
Header Rule | Applicable Parameter | Required Value(s) |
---|---|---|
Via | allow-header-param |
|
From | allow-header-param |
|
To | allow-header-param |
|
Call-ID | allow-header-param | No restrictions |
CSeq | allow-header-param | No restrictions |
Verify White List Configuration
After you configure and save a white list on the Oracle Communications Session Border Controller (OCSBC), you can use the verify-config command at the top level prompt to verify the saved configuration: For example:
ORACLE# verify-config
The verify-config command checks for errors in the OCSBC configuration. White list configuration errors specifically related to the enforcement-profile object also display in the output of this command when applicable. The white list configuration errors display if any references to the allowed-element-profiles are improperly configured. If errors exist, the system displays the following message:
---------------------------------------------------------------------
ERROR: enforcement-profile [ep] contains a reference to an allowed-enforcement-profile [abc] that does not exist
---------------------------------------------------------------------
How Whitelists Work
Whitelists allow you to customize which SIP signaling messages to allow into your network and which messages to reject or delete. In the flow of SIP traffic to/from the Oracle Communications Session Border Controller, the Oracle Communications Session Border Controller matches any received request or response, in or out of a dialog against the configured allowed list, and rejects or deletes the non-matching element based on the actions specified in the whitelist configuration.
For responses, the Oracle Communications Session Border Controller does not reject the message if a header or parameter is not found in the allowed list, even if the action is set to reject. Instead it deletes the offending parameter or header. In addition, if the message is a request of the method type ACK, PRACK, CANCEL or BYE, it deletes all unmatched elements, but does not reject the request, even if the action was configured to reject.
The whitelist verification performs for any method; however you can narrow this list to operate only on specific methods by defining them in the methods parameter of the configuration.
Whitelist verification occurs when a request or response is received by the Oracle Communications Session Border Controller, but only after the Oracle Communications Session Border Controller has processed the inbound header manipulation rule (HMR), network management controls (NMC), Resource-Priority header (RPH), and monthly-minutes checking.
The Oracle Communications Session Border Controller responds to requests which have non-matching headers or parameters configured with an action of reject, with a "403 Forbidden" response by default. You can use a local-response event, allowed-elements-profile-rejection, to override the default reject status code and reason phrase.
The configured whitelist operates transparently on headers that have multiple URIs or multiple header values within a single header (header values separated by a comma).
Parameter parsing operates only on parameters that it can identify. For parameters that can not be parsed, for example an invalid URI (e.g. <sip:user@host.com&hp=val>), the Oracle Communications Session Border Controller ignores this URI header parameter value of "hp" since it is not contained within a valid URI. Even though it would appear to be a URI header parameter, URI headers must come after URI parameters. Parameter matching does not occur if the headers and parameters in the URI are not well-formed. The Oracle Communications Session Border Controller does not remove the parameter since it cannot identify it.