Direct push optimization
June 25, 2014
Exchange ActiveSync (EAS) uses Direct Push technology to keep data on a Windows Phone device synchronized with data on a Microsoft Exchange server.
Direct Push optimization
Direct Push Technology has two parts; one resides on the phone (client), and the other resides on an Exchange Server:
Windows Phone (client): The EAS feature on the phone manages Direct Push communication with the Exchange server. It establishes an HTTP or HTTPS connection with the server for a specified time, and then it goes to sleep while waiting for the server to respond. The server responds with either a status indicating that new items were received or that no new items arrived. The phone then sends either a synchronization request or another Direct Push request. The rate at which this occurs is dynamically adjusted based on parameters set by the OEM or mobile operator and the time limits for an idle HTTP or HTTPS connection on the operator's network and the customer's enterprise network.
Exchange Server: An Exchange Server with the Client Access Server role installed has a Direct Push component that augments the Exchange ActiveSync infrastructure by supporting manual and scheduled synchronization. Exchange Server uses IP-based notifications to deliver email, contact, calendar, and task updates to a phone as soon as the information arrives at the server.
When data changes on the server, the changes are transmitted to the phone over a persistent HTTP or HTTPS connection that is used for Direct Push. The time-out value in the mobile operator's network specifies how long the persistent connection is maintained with no activity. To keep this connection from timing out between updates, the phone reissues a request when the server responds. This periodic transmission is referred to as the heartbeat. The heartbeat is what maintains the connection to the server for Direct Push; each heartbeat alerts the server that the phone is ready to receive data.
The Direct Push process
Direct Push traffic behaves like small HTTP requests to an Internet web site that takes a long time to issue a response. Microsoft recommends that the content of the packets be encrypted using Secure Sockets Layer (SSL) to make it difficult to identify Direct Push traffic by packet sniffing. The following steps describe the Direct Push process:
The client issues an HTTP message known as a ping request to an Exchange server, asking the server to report whether any changes occurred in the user’s mailbox within a specified time limit. In the ping request, the client specifies the folders that Exchange should monitor for changes. Typically, these are the inbox, calendar, contacts, and tasks.
When Exchange receives this request, it monitors the specified folders until one of the following occurs:
The time limit expires. The time limit is determined by the shortest time-out value in the network path. If this occurs, Exchange issues an HTTP 200 OK response to the client.
A change occurs in one of the folders, such as the arrival of mail. If this occurs, Exchange issues a response to the request and identifies the folder in which the change occurred.
The client reacts to the response from the Exchange server in one of the following ways:
If it receives an HTTP 200 OK response indicating that no change occurred, it reissues the ping request.
If it receives a response other than HTTP 200 OK, it issues a synchronization request for each folder that has changed. When the synchronization is complete, it reissues the ping request.
If it does not receive a response from the Exchange server within the time specified, it lowers the time interval in the ping request and reissues the request.
Direct Push Adjustment
During the Direct Push process, the phone waits for successive round trips before attempting to adjust the amount of time it needs to keep a connection open with the server. The amount of time that the server should wait for Personal Information Manager (PIM) changes or new mail to arrive before sending OK to the client is called the heartbeat interval.
The heartbeat interval is specified by the client and is sent as part of the ping request. The heartbeat begins at the default rate. The Direct Push algorithm on the client then dynamically adjusts the heartbeat interval to maintain the maximum time between heartbeats without exceeding the time-out value. The adjustment is based on network conditions, time limits on idle HTTP or HTTPS connections on the network, and some settings that the mobile operator can specify.
To determine the optimal heartbeat interval, the client keeps a log of ping requests. If a ping request receives a response, the client increases the interval. If no response is received at the end of the interval, the client determines that the network timed out and decreases the interval. Using this algorithm, the client eventually determines the longest idle connection possible across the wireless network and corporate firewall. The following steps describe the communication of how the heartbeat interval is adjusted during typical Direct Push communication between the client and the Exchange server:
The client wakes up and issues an HTTP request over the Internet to the Exchange server, and then goes to sleep. To keep the session active, the request specifies the heartbeat interval, which is the amount of time that the server should wait for PIM changes or new mail to arrive before sending OK to the client. In this illustration, the heartbeat interval is 15 minutes.
Because no mail arrived during the heartbeat interval, the server returns an HTTP 200 OK.
The client wakes up at the end of the heartbeat interval plus 1 minute (15 + 1 = 16 minutes total).
Because no mail arrived during the heartbeat interval, the server returns an HTTP 200 OK.
The server response wakes up the client. Because the connection did not time out during the interval, the client determines that the network can support idle connections for at least this length of time.
If this was a successive round trip, the client determines that it can increase the interval for the next request.
Direct Push and firewall settings
For Direct Push to work through the network firewall, TCP port 443 must be open. This port is required for Secure Sockets Layer (SSL) and must be opened between the Internet and the Client Access server.
The network idle connection time-out indicates how long a connection is permitted to live without traffic after a TCP connection is fully established.
The firewall session interval must be set to allow the heartbeat interval and enterprise session interval to communicate effectively. If the firewall closes the session, mail would be undelivered until the client reconnects, and the user could be unsynchronized for long periods of time. By setting the firewall session timeout equal to or greater than the idle timeout on the mobile operator's network, the firewall will not close the session.
Tip
Microsoft recommends setting the firewall's idle connection timeouts as follows: Mobile operators should set the idle connection timeouts on outgoing firewalls to 30 minutes. Organizations should set timeouts on their incoming firewalls to 30 minutes.
Web servers, network security appliances, and system network stacks have several time-based thresholds that are intended to insulate them from insufficiently tested or malicious clients. You can safely increase the idle connection time-out setting without compromising the security of the network. The following table shows examples of attacks and describes how other settings are used to mitigate exposure to them:
Denial of service (DoS) threat |
Mitigation of exposure to attacks |
|---|---|
A DoS attack is launched by failing to complete the handshake that is implicit in the creation of a TCP connection. The attacker attempts to create a large number of partially open TCP connections. |
Increasing the idle connection time-outs is unrelated to this type of attack. The time within which a TCP handshake must be completed is a separate threshold that is governed by the Windows TCP/IP stack. |
A DoS attack is launched against IIS by opening a large number of TCP connections but never issuing an HTTP request over any of them. |
Increasing the idle connection time-outs is unrelated to this type of attack. IIS mitigates this threat by requiring that a client submit a fully formed HTTP request within a certain time before dropping the connection. The name of the connection time-out setting in the IIS management console is misleading; TCP connections are closed when the connection time-out value is exceeded (120 seconds by default). |
An attacker establishes a large number of TCP connections, issues HTTP requests over all of them, but never consumes the responses. |
Increasing idle connection time-outs is unrelated to this type of attack. This threat is mitigated by the same time-out as the previous scenario. The connection time-out setting in IIS defines the time within which a client must issue either its first request after a TCP connection is established or a subsequent request in an HTTP keep-alive scenario. |
A short time-out value causes the mobile phone to initiate a new HTTPS request more frequently. This can shorten the battery life of the mobile phone. Higher heartbeat intervals result in longer battery life for the phone.