The direct push technology uses Exchange ActiveSync to keep data on a Windows Mobile–based device synchronized with data on a Microsoft Exchange server. There is no longer a reliance on SMS for notification.
Direct Push Technology
The direct push technology has two parts: one part resides on the device (client), and the other resides on an Exchange Server SP2 mail server. The following list describes these parts of the technology:
Windows Mobile–based device with MSFP. The ActiveSync technology on the device manages the direct push communication with Exchange Server. It establishes an HTTP or HTTPS connection with the server for a specified time, and then 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 device 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 Operator and how long an idle HTTP or HTTPS connection can be maintained on the operator network and the customer's Enterprise network.
Exchange Server 2003 Service Pack 2. This version of Exchange Server includes a direct push component that augments the Exchange ActiveSync infrastructure that supports manual and scheduled synchronization. Exchange Server uses IP-based notifications to deliver e-mail, contact, calendar, and task updates to a device as soon as the information arrives at the server.
When data changes on the server, the changes are transmitted to the device over a persistent HTTP or HTTPS connection that is used for direct push. The time-out value in the mobile operator network identifies how long the persistent connection will be maintained with no activity.
To keep this connection from timing out between updates, the device reissues a request when the server responds. This periodic transmission is referred as the "heartbeat". The heartbeat is what maintains the connection to the server for direct push; each heartbeat alerts the server that the device is ready to receive data.
The Direct Push Process
Direct push traffic looks 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 by using Secure Sockets Layer (SSL), which makes identifying direct push traffic by sniffing difficult.
The following steps provide an overview of the direct push process:
1. The client issues an HTTP message known as a ping request to an Exchange server, asking that the server report any changes that occur 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.
2. When Exchange receives this request, it monitors the folders specified until one of the following occurs:
The time limit expires. The time limit is determined by the shortest time out 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.
3. 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 error occurred, it re-issues the ping request.
If it receives a response other than HTTP 200 OK, it issues a synchronization request against each folder that has changed. When the synchronization is complete, it re-issues 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 then re-issues the request.
During the direct push process described above, the device 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 and how long an idle HTTP or HTTPS connection can be maintained on the operator or corporate network and some settings that the operator can specify.
To determine the optimal heartbeat interval, the algorithm keeps a log of ping requests. If a ping request receives a response, the algorithm increases the interval. If no response is received at the end of the interval, the client determines that the network timed out and the interval is decreased.
By using this algorithm, the client eventually determines the longest idle connection possible across the cellular network and corporate firewall.
The following illustration shows how the heartbeat interval is adjusted during typical direct push communication between the client and the Exchange Server.
The "T" in this illustration indicates the progression of time.
The following steps describe the communication; the numbers correspond to the numbers in the illustration:
1. 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 states the heartbeat interval, which is 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. In this illustration, the heartbeat interval is 15 minutes.
2. Because no mail arrived during the heartbeat interval, the server returns an HTTP 200 OK.
In this example, the response is lost because either the operator network or the Enterprise network was unable to sustain the long-lived HTTP connection; the client never receives it.
If the connection is closed by the back-end Exchange server, the device does not acknowledge the ended session and waits for the end of the heartbeat interval to reconnect.
3. The client wakes up at the end of the heartbeat interval plus 1 minute (15 1 = 16 minutes total).
The device waits for successive round trips before attempting to adjust the heartbeat interval. A tuning component in the algorithm can change the increments to an amount different than what is specified.
If this was a successive round trip with no response from the server, it issues a shorter-lived request (8 minutes).
In this example, because the heartbeat was not increased during the last ping, the heartbeat is changed to the minimum heartbeat value (8 minutes).
4. Because no mail arrived during the heartbeat interval, so the server returns an HTTP 200 OK.
5. 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.
The Impact of Direct Push on Networks and Exchange Servers
The algorithm that sets the heartbeat also minimizes bytes sent over the air and maximizes battery life.
Implementing data compression will reduce the packet sizes sent between the front end server and the client. However, the amount of bandwidth that is consumed and whether it will impact the user’s data plan greatly depends on the following factors:
What the user chooses to synchronize, such as more than the default folders.
How much data is changed in the mailbox and on the mobile device.
The Impact of Changing the Direct Push Settings
To help you maintain adequate device performance during direct push, Microsoft recommends values for the various direct push settings.
The heartbeat interval is set on the device by the mobile operator. Using a heartbeat interval of 30 minutes has positive implications for battery life and bandwidth consumption. When direct push sessions are permitted to live longer (such as 30 minutes), there are fewer HTTP round trips, less data sent and received, and less power consumed by the device.
A heartbeat interval that is too short will keep the user always up to date, but will shorten battery life because of the constant pinging to the server.
If a device that has a heartbeat below the minimum heartbeat level requests a connection to the Exchange server, the server logs an event to indicate to the administrator that direct push is not working.
To have device information being up to date and yet still have the battery life as long as possible, the Exchange server session duration should be a little greater than the maximum heartbeat setting, If the server session is shorter, it may reach idle timeout causing it to drop the session. This would result in mail being undeliverable until the client reconnects, and the user could be unsynchronized for long periods of time.
The network idle connection timeout 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 freely. If the firewall closes the session, then mail would be undeliverable 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 Operator network, the firewall will not close the session.
The following list shows how the firewalls idle connection timeouts should be set:
Operators need to set the idle connection timeouts on outgoing firewalls to 30 minutes.
Enterprises also need to 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 timeout setting without compromising the security of the network.
In a direct push scenario, the connection is idle between the time that the HTTP request is made and either the time that the heartbeat interval expires or when the server responds to the request with a change (such as when mail is received). Direct push makes no assumption as to the length of its sessions; E-mail is delivered rapidly whether the heartbeat interval is one minute or thirty minutes.
Increasing the idle connection timeout typically does not increase or decrease the exposure to attack. The following table shows examples of attacks and describes how other settings are used to mitigation exposure to them.
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 timeouts is unrelated to this type of attack.
The time within which a TCP handshake must complete 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 timeouts 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 Timeout setting in the IIS management console is misleading; TCP connections are closed when the Connection Timeout 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 timeouts is unrelated to this type of attack.
This threat is mitigated by the same timeout as the previous scenario. The Connection Timeout 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.