Information about the Cisco Mobility Advantage Proxy Feature
This section contains the following topics:
Cisco Mobility Advantage Proxy Functionality
To support Cisco UMA for the Cisco Mobility Advantage solution, the mobility advantage proxy (implemented as a TLS proxy) includes the following functionality:
The ability to allow no client authentication during the handshake with clients.
Allowing an imported PKCS-12 certificate to server as a proxy certificate.
The ASA includes an inspection engine to validate the Cisco UMA Mobile Multiplexing Protocol (MMP).
MMP is a data transport protocol for transmitting data entities between Cisco UMA clients and servers. As shown in Figure 1-1, MMP must be run on top of a connection-oriented protocol (the underlying transport) and is intended to be run on top of a secure transport protocol such as TLS. The Orative Markup Language (OML) protocol is intended to be run on top of MMP for the purposes of data synchronization, as well as the HTTP protocol for uploading and downloading large files.
Figure 1-1 MMP Stack
The TCP/TLS default port is 5443. There are no embedded NAT or secondary connections.
Cisco UMA client and server communications can be proxied via TLS, which decrypts the data, passes it to the inspect MMP module, and re-encrypt the data before forwarding it to the endpoint. The inspect MMP module verifies the integrity of the MMP headers and passes the OML/HTTP to an appropriate handler. The ASA takes the following actions on the MMP headers and data:
Verifies that client MMP headers are well-formed. Upon detection of a malformed header, the TCP session is terminated.
Verifies that client to server MMP header lengths are not exceeded. If an MMP header length is exceeded (4096), then the TCP session is terminated.
Verifies that client to server MMP content lengths are not exceeded. If an entity content length is exceeded (4096), the TCP session is terminated.
Note 4096 is the value currently used in MMP implementations.
Because MMP headers and entities can be split across packets, the ASA buffers data to ensure consistent inspection. The SAPI (stream API) handles data buffering for pending inspection opportunities. MMP header text is treated as case insensitive and a space is present between header text and values. Reclaiming of MMP state is performed by monitoring the state of the TCP connection.
Mobility Advantage Proxy Deployment Scenarios
Figure 1-2 and Figure 1-3 show the two deployment scenarios for the TLS proxy used by the Cisco Mobility Advantage solution. In scenario 1 (the recommended deployment architecture), the ASA functions as both the firewall and TLS proxy. In scenario 2, the ASA functions as the TLS proxy only and works with an existing firewall. In both scenarios, the clients connect from the Internet.
In the scenario 1 deployment, the ASA is between a Cisco UMA client and a Cisco UMA server. The Cisco UMA client is an executable that is downloaded to each smartphone. The Cisco UMA client applications establishes a data connection, which is a TLS connection, to the corporate Cisco UMA server. The ASA intercepts the connections and inspects the data that the client sends to the Cisco UMA server.
Figure 1-2 The TLS proxy for the Cisco Mobility Advantage solution does not support client authentication because the Cisco UMA client cannot present a certificate. Security Appliance as Firewall with Mobility Advantage Proxy and MMP Inspection
In Figure 1-2, the ASA performs static NAT by translating the Cisco UMA server 10.1.1.2 IP address to 192.0.2.140.
Figure 1-3 shows deployment scenario 2, where the ASA functions as the TLS proxy only and does not function as the corporate firewall. In this scenario, the ASA and the corporate firewall are performing NAT. The corporate firewall will not be able to predict which client from the Internet needs to connect to the corporate Cisco UMA server. Therefore, to support this deployment, you can take the following actions:
Set up a NAT rule for inbound traffic that translates the destination IP address 192.0.2.41 to 172.16.27.41.
Set up an interface PAT rule for inbound traffic translating the source IP address of every packet so that the corporate firewall does not need to open up a wildcard pinhole. The Cisco UMA server receives packets with the source IP address 22.214.171.124.
See Chapter 1, “Configuring Network Object NAT (ASA 8.3 and Later)” and Chapter 1, “Configuring Twice NAT (ASA 8.3 and Later)” for information.
Note This interface PAT rule converges the Cisco UMA client IP addresses on the outside interface of the ASA into a single IP address on the inside interface by using different source ports. Performing this action is often referred as “outside PAT”. “Outside PAT” is not recommended when TLS proxy for Cisco Mobility Advantage is enabled on the same interface of the ASA with phone proxy, Cisco Unified Presence, or any other features involving application inspection. “Outside PAT” is not supported completely by application inspection when embedded address translation is needed.
Figure 1-3 Cisco UMC/Cisco UMA Architecture – Scenario 2: Security Appliance as Mobility Advantage Proxy Only
Mobility Advantage Proxy Using NAT/PAT
In both scenarios (Figure 1-2 and Figure 1-3), NAT can be used to hide the private address of the Cisco UMA servers.
In scenario 2 (Figure 1-3), PAT can be used to converge all client traffic into one source IP, so that the firewall does not have to open up a wildcard pinhole for inbound traffic.
Trust Relationships for Cisco UMA Deployments
To establish a trust relationship between the Cisco UMC client and the ASA, the ASA uses the Cisco UMA server certificate and keypair or the ASA obtains a certificate with the Cisco UMA server FQDN (certificate impersonation). Between the ASA and the Cisco UMA server, the ASA and Cisco UMA server use self-signed certificates or certificates issued by a local certificate authority.
Figure 1-4 shows how you can import the Cisco UMA server certificate onto the ASA. When the Cisco UMA server has already enrolled with a third-party CA, you can import the certificate with the private key onto the ASA. Then, the ASA has the full credentials of the Cisco UMA server. When a Cisco UMA client connects to the Cisco UMA server, the ASA intercepts the handshake and uses the Cisco UMA server certificate to perform the handshake with the client. The ASA also performs a handshake with the server.
Figure 1-4 How the Security Appliance Represents Cisco UMA – Private Key Sharing
Figure 1-5 shows another way to establish the trust relationship. Figure 1-5 shows a green field deployment, because each component of the deployment has been newly installed. The ASA enrolls with the third-party CA by using the Cisco UMA server FQDN as if the ASA is the Cisco UMA server. When the Cisco UMA client connects to the ASA, the ASA presents the certificate that has the Cisco UMA server FQDN. The Cisco UMA client believes it is communicating to with the Cisco UMA server.
Figure 1-5 How the Security Appliance Represents Cisco UMA – Certificate Impersonation
A trusted relationship between the ASA and the Cisco UMA server can be established with self-signed certificates. The ASA's identity certificate is exported, and then uploaded on the Cisco UMA server truststore. The Cisco UMA server certificate is downloaded, and then uploaded on the ASA truststore by creating a trustpoint and using the
crypto ca authenticate
Licensing for the Cisco Mobility Advantage Proxy Feature
The Cisco Unified Communications proxy features (Cisco Phone Proxy, TLS proxy for encrypted voice inspection, and the Cisco Presence Federation Proxy) supported by the ASA require a Unified Communications Proxy license. However, in Version 8.2(2) and later, the Mobility Advantage proxy no longer requires a Unified Communications Proxy license.
The following table shows the licensing requirements for the Mobility Advantage proxy:
For more information about licensing, see Chapter1, “Managing Feature Licenses”
Configuring Cisco Mobility Advantage
This section includes the following topic:
Task Flow for Configuring Cisco Mobility Advantage
To configure for the ASA to perform TLS proxy and MMP inspection as shown in Figure 1-2 and Figure 1-3, perform the following tasks.
It is assumed that self-signed certificates are used between the ASA and the Cisco UMA server.
To configure the Cisco Mobility Advantage Proxy by using ASDM, choose Wizards > Unified Communications Wizard from the menu. The Unified Communications Wizard opens. From the first page, select the Cisco Mobility Advantage Proxy option under the Remote Access section.
The wizard automatically creates the necessary TLS proxy, then guides you through creating the Unified Presence Proxy instance, importing and installing the required certificates, and finally enables the MMP inspection for the Mobility Advantage traffic automatically.
The wizard guides you through four steps to create the Mobility Advantage Proxy:
Step 1 Select the Mobility Advantage Proxy option.
Step 2 Specify setting to define the proxy topology, such the IP address of the Mobility Advantage server.
Step 3 Configure the server-side certificate management, namely the certificates that are exchanged between the local Mobility Advantage server and the ASA.
Step 4 Configure the client-side certificate management, namely the certificates that are exchanged between the Unified Mobile Communicator and the ASA
The wizard completes by displaying a summary of the configuration created for Mobility Advantage Proxy. See Chapter 1, “Using the Cisco Unified Communication Wizard” for more information.