This section provides added context about key configuration items that relate to Cisco Spark Calling for Branch Offices.

We've highlighted these items in particular for the following reasons:

• We want to explain them, so that you understand their role in a Cisco Spark Calling for Branch Offices deployment and feel reassured.

• They are mandatory prerequisites that ensure a secure deployment between our cloud and your on-premises environment.

• They should be treated as pre-day zero activities: they can take a bit longer to complete than typical configuration in a user interface, so allow a timeframe to get these items sorted.

• After these items are addressed in your environment, the rest of your Cisco Spark Calling for Branch Offices configuration will go smoothly.

The Expressway-C and Expressway-E pair deployment allows calls to and from the Internet using firewall traversal technologies. This deployment is what securely takes your on-premises call control and ties it in to Cisco Spark through the Cisco Collaboration Cloud.

The Expressway-C and Expressway-E don't require any inbound port to be opened in the demilitarized zone (DMZ) firewall because of the firewall traversal architecture. But TCP SIP signaling ports and UDP media ports must be opened inbound on the Internet firewall to let incoming calls come through. You must allow time to have the appropriate port opened on your enterprise firewall.

The firewall traversal architecture is shown in the following diagram:

For example, for inbound business-to-business (B2B) calls using SIP protocol, TCP ports 5060 and 5061 (5061 is used for SIP TLS) must be opened on the external firewall, together with UDP media ports used for services such as voice, video, content sharing, dual video, and so on. Which media ports to open depends on the number of concurrent calls and the number of services.

You can configure the SIP listening port on Expressway to be any value between 1024 to 65534. At the same time, this value and the protocol type must be advertised in the public DNS SRV records, and that same value must be opened on the Internet firewall.

Though the standard for SIP TCP is 5060 and for SIP TLS 5061, nothing prevents use of different ports, as the following example shows.

Example

In this example, we assume that port 5062 is used for inbound SIP TLS calls.

The DNS SRV record for a cluster of two Expressway servers looks like this:

_sips._tcp.example.com SRV service location:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe1.example.com

_sips._tcp.example.com SRV service location:

priority = 10

weight = 10

port = 5062

svr hostname = us-expe2.example.com

These records mean that calls are directed to us-expe1.example.com and us-expe2.example.com with equal load sharing (priority and weight) using TLS as the transport type and 5062 as the listening port number.

A device that is external to the network (on the Internet) and that makes a SIP call to a user of the corporate domain (user1@example.com) must query the DNS to understand which transport type to use, the port number, how to load-share the traffic, and which SIP servers to send the call to.

If the DNS entry includes _sips._tcp, the entry specifies SIP TLS.

TLS is a client-server protocol and, in the most common implementations, uses certificates for authentication. In a business-to-business call scenario, the TLS client is the calling device, and the TLS server is the called device. With TLS, the client checks the certificate of the server, and if the certificate check fails, it disconnects the call. The client doesn't need a certificate.

TLS handshake is shown in the following diagram:

However, the TLS specification states that the server can also check the client certificate by sending a Certificate Request message to the client during TLS handshake protocol. This message is helpful on a server-to-server connection, such as on call that is established between Expressway-E and the Cisco Collaboration Cloud. This concept is called TLS with mutual authentication and is required when integrating with Cisco Spark.

Both the calling and called parties check the certificate of the other peer, as the following diagram shows:

The cloud checks the Expressway identity, and Expressway checks the cloud identity. For example, if the cloud identity in the certificate (CN or SAN) doesn't match what's configured on Expressway, the connection is dropped.

If mutual authentication is turned on, Expressway-E always requests the client certificate. As a result, Mobile and Remote Access (MRA) won't work, because in most cases certificates are not deployed on Jabber clients. In a business-to-business scenario, if the calling entity is not able to provide a certificate, the call is disconnected.

We recommend that you use a value other than 5061 for TLS with mutual authentication, such as port 5062. Cisco Spark Hybrid Services use the same SIP TLS record used for B2B. In the case of port 5061, some other services that cannot provide a TLS client certificate won't work.

Business-to-business, Mobile and Remote Access and Cisco Spark traffic on the same Expressway pair

Business-to-business and Mobile and Remote Access calls use port 5061 for SIP TLS, and Cisco Spark traffic uses port 5062 for SIP TLS with mutual authentication.

The domain ownership check is part of identity verification. Domain verification is a security measure and identity check that the Cisco Collaboration Cloud implements to prove that you are who you say you are.

The identity check is performed in two stages:

1. Domain ownership check. This step involves three types of domains and is a one-time verification check:

   • Email domain

   • Expressway-E DNS domain

   • Directory URI domain

2. Expressway-E DNS name ownership check. This step is performed through the implementation of TLS with mutual authentication and involves the use of public certificates on both the cloud and the Expressway. Unlike the domain identity check, this step is performed during any call made to and received from the cloud.

A Story to Show the Importance of the Domain Ownership Check

The Cisco Collaboration Cloud performs the domain ownership check to enforce security. Identity theft is one possible threat if this check is not performed.

The following story details what might happen if a domain ownership check is not performed.

A company with DNS domain set to "hacker.com" buys Cisco Spark Hybrid Services. Another company, with its own domain set to "example.com", is also using Cisco Spark Calling. One of the general managers of the company Example.com is named Jane Roe and has the directory URI jane.roe@example.com.

The administrator of Hacker.com company sets one of her directory URIs to jane.roe@example.com and the email address to jane.roe@hacker.com. She can do that because the cloud doesn't check the SIP URI domain in this example.

Next, she signs in to Cisco Spark with jane.roe@hacker.com. Because she owns the domain, the verification email is read and answered, and she can sign in. Finally, she makes a call to a colleague, John Doe, by dialing john.doe@example.com from her Cisco Spark app. John is sitting in his office and sees a call on his video device coming from jane.roe@example.com; that is the directory URI associated with that email account.

"She's abroad," he thinks. "She might need something important." He answers the phone, and the fake Jane Roe asks for important documents. She explains that her device is broken, and because she is travelling, she asks him to send the documents to her private email address, jane.roe@hacker.com. This way, the company realizes only after Jane Roe gets back to the office that important information was leaked outside of the company.

The company Example.com has many ways to protect against fraudulent calls coming from the Internet, but one of the responsibilities of the Cisco Collaboration Cloud is to make sure that the identity of anyone calling from Cisco Spark is correct and not falsified.

To check the identity, Cisco Spark requires that the company proves that it owns the domains used in Cisco Spark Calling. If it doesn't, Cisco Spark Calling won't work.

To ensure this ownership, the two domain verification steps are required:

1. Prove that the company owns the email domain, Expressway-E domain, Directory URI domain.

   • All those domains must be routable and known by public DNS servers.

   • To prove the ownership, the DNS administrator must enter a DNS Text record (TXT). A TXT record is a type of resource record in the DNS used to provide the ability to associate some arbitrary and unformatted text with a host or other name.

   • The DNS administrator must enter that TXT record in the zone whose ownership must be proved. After that step, the Cisco Collaboration Cloud performs a TXT record query for that domain.

   • If the TXT query is successful and the result matches the token that was generated from the Cisco Collaboration Cloud, the domain is verified.

   • As an example, the administrator must prove that she owns the domain "example.com", if she wants that Cisco Spark and Cisco Spark Hybrid Services to work on her domain.

   • Through https:/​/​admin.ciscospark.com, she starts the verification process by creating a TXT record to match the token that the Cisco Collaboration Cloud generated:

     
     
     
   • The DNS administrator then creates a TXT record for this domain with the value set to 123456789abcdef123456789abcdef123456789abcdef123456789abcdef, as in the following example:

     
     
     

   • At this point, the cloud can verify that the TXT record for the domain example.com matches the token.

   • The cloud performs a TXT DNS lookup:

     
     
     

   • Because the TXT value matches the token value, this match proves that the administrator added the TXT record for her own domain to the public DNS, and that she owns the domain.

2. Expressway-E DNS Name ownership check.

   • The cloud must check that the Expressway-E has a confirmed identity from one of the certificate authorities that the cloud trusts. The Expressway-E administrator must request a public certificate for his Expressway-E to one of those certificate authorities. To issue the certificate, the certificate authority performs an identity verification process, based on a domain validation check (for domain validated certificates) or organization validation check (for organization validated certificates).

   • Calls to and from the cloud depend on the certificate that was issued to the Expressway-E. If the certificate is not valid, the call is dropped.

The Expressway-C connector host must be registered to the Cisco Collaboration Cloud in order for Cisco Spark Calling for Branch Offices to work.

Expressway-C is deployed in the internal network, and the way it registers to the cloud is through an outbound HTTPS connection—the same type that is used for any browser that connects to a web server.

Registration and communication to the Cisco Collaboration Cloud uses TLS. Expressway-C is the TLS client, and the Cisco Collaboration Cloud is the TLS server. As such, Expressway-C checks the server certificate.

The certificate authority signs a server certificate using its own private key. Anyone with the public key can decode that signature and prove that the same certificate authority signed that certificate.

If Expressway-C has to validate the certificate provided by the cloud, it must use the public key of the certificate authority that signed that certificate to decode the signature. A public key is contained in the certificate of the certificate authority. To establish trust with the certificate authorities used by the cloud, the list of certificates of these trusted certificate authorities must be in the Expressway's trust store. Doing so, the Expressway can verify that the call is truly coming from the Cisco Collaboration Cloud.

With manual upload, you can upload all relevant certificate authority certificates to the trust store of Expressway-C.

With automatic upload, the cloud itself uploads those certificates in the trust store of Expressway-C. We recommend that you use automatic upload. The certificate list might change, and automatic upload guarantees that you get the most updated list.

If you allow automatic installation of certificate authority certificates, you are redirected to https:/​/​admin.ciscospark.com (the management portal). The redirection is done by the Expressway-C itself without any user intervention. You, as the Cisco Spark administrator, must authenticate through an HTTPS connection. Soon after, the cloud pushes the CA certificates to the Expressway-C.

Until the certificates are uploaded to the Expressway-C trust store, the HTTPS connection cannot be established.

To avoid this problem, the Expressway-C is preinstalled with Cisco Spark-trusted CA certificates. Those certificates are only used to set up and validate the initial HTTPS connection, and they don't appear in Expressway-C trust list. Once the certificates of the trusted certificate authorities are pulled from the cloud through this initial HTTPS connection, those certificates are available for platform-wide usage; then, they appear in the Expressway-C trust list.

This list shows the certificate authority certificates that the Cisco Collaboration Cloud currently uses. This list might change in the future:

• C=IE, O=Baltimore, OU=CyberTrust, CN=Baltimore CyberTrust Root

• C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root

• C=US, O=The Go Daddy Group, Inc., OU=Go Daddy Class 2 Certificate Authority

• C=US, ST=Arizona, L=Scottsdale, O=GoDaddy.com, Inc., CN=Go Daddy Root Certificate Authority - G2

• C=BM, O=QuoVadis Limited, CN=QuoVadis Root CA 2

• C=US, O=thawte, Inc., OU=Certification Services Division, OU=(c) 2006 thawte, Inc. - For authorized use only, CN=thawte Primary Root CA

• C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certificate Authority

A list of certificate authority certificates is also required for the Expressway-E in the traversal pair. Expressway-E communicates with the Cisco Collaboration Cloud using SIP with TLS, enforced by mutual authentication. Expressway-E trusts calls coming from and going to the cloud, only if the CN or SAN of the certificate presented by the cloud during TLS connection setup matches the subject name configured for the DNS zone on Expressway ("callservice.ciscospark.com"). The certificate authority releases a certificate only after an identity check. The ownership of the callservice.ciscospark.com domain must be proved to get a certificate signed. Because we (Cisco) own that domain, the DNS name "callservice.ciscospark.com" is direct proof that the remote peer is truly the Cisco Collaboration Cloud.

Expressway-C and Expressway-E used for SIP signaling and media

You can have multiple Expressway-C and Expressway-E clusters in different regions. Unified CM uses the nearest Expressway clusters for outbound calls from Unified CM to the Cisco Collaboration Cloud, based on partitions and calling search space configuration.

For inbound calls, you must understand how to split the traffic between the different Expressway-E clusters of the Internet Edge.

• If the Internet Edges are deployed in the same datacenter or in the same area, load balancing can occur at the DNS SRV level. As an example, if the enterprise network includes three Internet Edges used for Cisco Spark Hybrid Calling, each one consisting of a cluster of two Expressway-E and Expressway-C nodes, the _sips._tcp.example.com will include all six Expressway-E records (3 Expressway-Es multiplied by 2) with the same priority and weight. This setup distributes the calls from the Cisco Collaboration Cloud equally across the various Expressway-E and Expressway-C clusters.

• If the Internet Edges are deployed across different regions, the best solution is to use Geo DNS services.

  Geo DNS services are delivered by many DNS providers, and are based on the ability of the Geo DNS to check the source IP address, understand what country or region that IP address belongs to, and forward the request to the edge that is physically closest to that region.

  Based on this classification, and on the configuration on the Geo DNS, the call is sent to the Expressway-E that is physically nearest to the zone to which the calling IP address belongs.

As an example, AWS Geo DNS services are configured in the following way:

Once the SRV record is created, a "Location" label is applied and the country is specified. A call coming from the cloud with an IP address that is part of the same location (Italy, in this example) is sent to emea-expe1.example.com. Many SRV records can be created based on the number of regions.

Configuration of Geo DNS depends on the DNS provider, and this configuration example is for reference purposes only.

In case of two different Expressway-C and Expressway-E clusters deployed in the US and EMEA, the DNS SRV record _sips._tcp.example.com is configured as belonging to two different zones. Using AWS requires two DNS SRV records for _sips._tcp.example.com, as the following example shows:

This way, a call leaving the Cisco Collaboration Cloud in US enters the Expressway-E in US, and only in the case where that Expressway-E cluster in US is not available, the Expressway-E cluster in EMEA is used. If the call leaves the Cisco Collaboration Cloud in EMEA, it goes in to the Expressway-E cluster located in EMEA and uses the US cluster only if the EMEA cluster is unavailable.