The Impact of Changing the Direct Push Settings

Article
06/03/2010

6/2/2010

To help you maintain adequate device performance during direct push, Microsoft recommends values for the various direct push settings. These are described in Recommended Values.

Heartbeat Interval

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.

Minimum Heartbeat

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.

Exchange Session

To have device information being up to date and yet still have 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.

Firewall Timeouts

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 increase the idle connection timeouts on outgoing firewalls to 30 minutes.
Enterprises also need to increase 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.

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 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.

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.

The Impact of Changing the Direct Push Settings

Heartbeat Interval

Minimum Heartbeat

Exchange Session

Firewall Timeouts

See Also

Concepts

Additional resources