You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

 

 

The

Unable to show "metadata-from": No such page "_space_variables"
 supports registration relay support in an IBCF environment consisting of the following parts:

  • Unable to show "metadata-from": No such page "_space_variables"
     processing/forwarding REGISTER requests without creating any RCB (registration control block).
  • Passing of Path and Service-Route headers (included in REGISTER request and response messages) end to end with support for encryption for topology hiding purpose. "Via" headers are handled in a B2BUA role (i.e. the
    Unable to show "metadata-from": No such page "_space_variables"
     stores the incoming Via and inserts its URI in outgoing messages).
  • Decryption of Route headers in non-REGISTER requests (in an IMS deployment, Route headers are formed based on Path and Service Route headers included in REGISTER request and response message. the
    Unable to show "metadata-from": No such page "_space_variables"
     must decrypt them for routing purpose).
  • IBCF continues to act as a B2BUA with respect to non-REGISTER message processing, so topology revealing headers encryption is NOT applicable to non-REGISTER messages.
  • Registration rate limit CAC related enhancements in the context of registration relay support on IBCF.

Overview

At a high-level, the following steps are needed for the

Unable to show "metadata-from": No such page "_space_variables"
 to act as a registration relay:

  • Transparently pass the received headers
  • Insert itself on top of the received headers
  • Perform encryption

The

Unable to show "metadata-from": No such page "_space_variables"
 as IBCF supports relay of registration messages using the flag sipRegRelay which is configurable per Zone level and associated with ingress Zone with respect to message direction.

When registration relay functionality is enabled, the following behavior applies:

  • The
    Unable to show "metadata-from": No such page "_space_variables"
     relays REGISTER using the routes from PSX.
  • When “Require registration” flag is also enabled, relay functionality takes higher precedence and provisioned value of the “Require registration” flag is ignored.
  • Registration message relayed by the
    Unable to show "metadata-from": No such page "_space_variables"
     are NOT subject to any throttling.
    • The
      Unable to show "metadata-from": No such page "_space_variables"
       ignores provisioned registration “expires” and “insideExpiresMinimum” values (typically used for registration message throttling for UE behind NAT scenarios).
    • The
      Unable to show "metadata-from": No such page "_space_variables"
       passes the registration expiry value received in the ingress registration message transparently to the egress message. This is applicable to both REGSITER request and 200 OK response messages. 
  • The
    Unable to show "metadata-from": No such page "_space_variables"
     as IBCF does NOT add the Path and Service-Route headers included in the emergency registration requests and responses if noServiceRouteHdrForEmergencyRegistration is enabled, even if createServiceRouteHeader flag is enabled.
  • The
    Unable to show "metadata-from": No such page "_space_variables"
      ignores provisioned “storePathHeader” and “serviceRouteHeader” values (typically provisioned on SBC to act as B2BUA with respect to Path and Service-Route header processing).
  • The
    Unable to show "metadata-from": No such page "_space_variables"
     as IBCF supports transparency of the following headers in REGISTER requests and responses if registration relay functionality is enabled.
    • Contact header and parameters (excluding transport parameter).

    • Expires header

      Since Contact header always points to either UE or P-CSCF included URI passing the transport parameter to next hop with IBCF being in the path may NOT serve any purpose. 
Enabling registration relay functionality supersedes any of provisioned values for existing transparency flags, and always passes these headers transparently.

The

Unable to show "metadata-from": No such page "_space_variables"
 as IBCF can route non-REGISTER requests based on the received route set. Options include:

  • routing the message based on PSX username/standard routing provisioning if NO route headers are received in the incoming message. The
    Unable to show "metadata-from": No such page "_space_variables"
     inserts the next-hop as the top-most Route header based on (existing) configuration.
  • routing the message based on PSX username/standard routing provisioning if there is one Route header and that points to IBCF. The
    Unable to show "metadata-from": No such page "_space_variables"
     inserts the next-hop as the top-most Route header based on (existing) configuration. The
    Unable to show "metadata-from": No such page "_space_variables"
     copies any parameters present in the received ingress Route header (pointing to itself) in the egress Route header (pointing to next-hop).

The

Unable to show "metadata-from": No such page "_space_variables"
 as IBCF can prevent the addition of Service-Routes pointing to IBCF (both internal and external interface IP addresses) in 200 OK response.

  • This behavior is controlled by provisioning flag associated with egress TG with respect to message direction.
  • If this flag is enabled then provisioned values of “createServiceRouteHeader” and “addPathServiceRoute” is ignored.

A Service-Route is not inserted in default deployment as IBCF.

Network Topology Hiding Support

The

Unable to show "metadata-from": No such page "_space_variables"
 supports network topology hiding, including following behavior: The
Unable to show "metadata-from": No such page "_space_variables"
 as IBCF performs encryption for network topology hiding purposes under the following conditions:

  • upon receiving an outgoing request/response from the trusted/hiding network,
  • upon receiving and incoming requests/response towards the trusted/hiding network.

Header transparency is controlled using the dynamic header Transparency Profile (Note that contact and expires headers are transparently passed by default).

The

Unable to show "metadata-from": No such page "_space_variables"
 adds itself to the appropriate headers so as to remain in the path. In other words, the step of transparently passing and inserting itself to the header-list is different than performing encryption.

  • When the request/response traverses from trusted network to untrusted network, encryption is performed.
  • When the request/response traverses from untrusted network to trusted network, encryption is not performed.

Emergency Registration

The flag noServiceRouteHdrForEmergencyRegistration controls whether the

Unable to show "metadata-from": No such page "_space_variables"
 as IBCF adds itself to Service-Route headers in the 200 OK to emergency registration requests.

Encryption/Decryption Enhancements

The

Unable to show "metadata-from": No such page "_space_variables"
 as IBCF supports following encryption/decryption functionality using IP Signaling Profile's headerEncryptionFlags encryptPathHeader/encryptServiceRouteHeader:

  • Encryption of Path headers included in REGISTER requests.
  • Encryption of Path and Service-Route headers included in the 200 OK to REGISTER message.
  • Decryption of Path headers included in the 200 OK to REGISTER message.
  • Decryption of Route headers included in the non-REGISTER requests such as dialog creating INVITE and OOD non-INVITE messages such as SUBSCRIBE, OOD MESSAGE, OPTIONS, REFER etc.

The

Unable to show "metadata-from": No such page "_space_variables"
 as IBCF encrypts the topology revealing headers in the request and response messages before forwarding.

 

While the ability to encrypt is configurable, no configuration is required to decrypt messages. When receiving messages from an untrusted network and there is no need to encrypt the messages, by default the corresponding headers that were earlier encrypted are automatically decrypted.

The

Unable to show "metadata-from": No such page "_space_variables"
 as IBCF supports the encryption of the topology revealing headers using the following logic:

  • Copy all headers considered for encryption from ingress SIP message towards the egress SIP message. This behavior is controlled by transparency flag pertaining to the header to be encrypted.
  • Insert own URI(s) before the headers entries to be considered for encryption.
  • Encrypt the headers based on encryption logic discussed in subsequent requirements.

The Global command generateSipHeaderEncryptionKeys generates header encryption keys for AES encryption. The

Unable to show "metadata-from": No such page "_space_variables"
 stores up to two sets of keys at any given time, with each key having a specific key ID. The user can issue the generateSipHeaderEncryptionKeys command at any time. There is no specific time delay before reissuing the command. The
Unable to show "metadata-from": No such page "_space_variables"
 adds the key-Id to each encrypted header based on which key is selected as the correct key for decryption.

Generating new keys too frequently may lead to a situation where the

Unable to show "metadata-from": No such page "_space_variables"
receives a request with an expired key-id (i.e. the current header encryption key is over-written due to the new key generation) causing unsuccessful decryption of headers. This may lead to call failures any calls caught in the transition to the new key-id.

CAC Control on Register Relay Messages

Since the

Unable to show "metadata-from": No such page "_space_variables"
 as IBCF relays registration messages without creating any RCB, Registration Limit CAC functionality is not applicable and must not be enabled at IBCF. The
Unable to show "metadata-from": No such page "_space_variables"
 only applies Registration Rate and Registration Burst Rate CAC on register relay messages. Only new Register messages are subjected to CAC in case of Register Relay. If the Authorization header has an integrity-protected parameter with value “no” or if there is no integrity-protected parameter, SBC identifies it as a fresh Register Message. If the integrity-protected parameter has other values like “yes”, “tls-yes”, “tls-pending”, “ip-assoc-pending”, “ip-assoc-yes”,
Unable to show "metadata-from": No such page "_space_variables"
 identifies it as a refresh Register Message.

 

  • No labels