Internet Draft: Deployment Considerations for
lemonade-compliant Mobile Email R. Gellens
Document: draft-ietf-lemonade-deployments-00.txt Qualcomm
Expires: August 2006 February 2005
Deployment Considerations for lemonade-compliant Mobile Email
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Abstract
This document discusses deployment issues and describes implicit
requirements for successful deployment of mobile email based on the
IETF lemonade documents.
Gellens [Page 1] Expires August 2006
Internet Draft Lemonade Deployment Considerations February 2006
Table of Contents
1 Conventions Used in this Document . . . . . . . . . . . . . . 2
2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4 TCP Connections . . . . . . . . . . . . . . . . . . . . . . . 3
4.1 Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 3
4.2 Maintenance during temporary transport loss . . . . . . . 3
5 Dormancy . . . . . . . . . . . . . . . . . . . . . . . . . . 3
6 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7 Security Considerations . . . . . . . . . . . . . . . . . . . 4
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
10 Normative References . . . . . . . . . . . . . . . . . . . . . 6
11 Informative References . . . . . . . . . . . . . . . . . . . 6
12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property Statement . . . . . . . . . . . . . . . 6
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7
1 Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
2 Introduction
The IETF lemonade group has developed a set of extensions to IMAP
and Message Submission, along with a profile document which
restricts server behavior and describes client usage [PROFILE].
Successful deployment of lemonade-compliant mobile email requires
additional functionality, which is generally assumed and hence often
not covered in email RFCs. This document describes some of these
additional considerations, with a focus on those which have been
reported to be problematic.
3 Ports
Both IMAP and Message Submission have been assigned well-known ports
[IANA] which MUST be available. IMAP uses port 143. Message
Submission uses port 587. It is REQUIRED that the client be able to
contact the server on these ports. Hence the client and server
systems, as well as any intermediary systems, MUST allow
communication on these ports.
Gellens [Page 2] Expires August 2006
Internet Draft Lemonade Deployment Considerations February 2006
In addition to communications between the client and server systems,
lemonade forward-without-download requires that the Message
Submission server be able to establish a TCP connection to the IMAP
server. Unless specially configured, this uses port 143.
It should be noted that systems which don't support TCP on arbitrary
ports aren't full Internet clients. As a result, such systems must
use gateways to the Internet which necessarily result in data
integrity problems.
4 TCP Connections
Both IMAP and Message Submission use TCP. Hence the client system
MUST be able to establish and maintain TCP connections to these
servers. The Message Submission server MUST be able to initiate a
connection to the IMAP server.
4.1 Lifetime
The duration of the TCP connections between the client and server
systems for both IMAP and Message Submission can be arbitrarily
long. The client system, the server, as well as all intermediate
systems MUST NOT terminate these TCP connections simply because of
their duration. Both protocols do permit application-level timeouts
if no data is received within a period of time, under the control of
the server. However, it has been reported that some mobile carrier
network infrastructure elements impose time restrictions of their
own on TCP connections other than HTTP. Such behavior is harmful to
mobile email and all other TCP-based protocols. It is unclear how
widespread such reported behavior is, or if it is an accidental
consequence of an attempt at optimizing for HTTP traffic or a
deliberate choice. Either way, such a barrier to TCP connections is
a significant risk to the increasing usage of IETF protocols on
mobile networks.
4.2 Maintenance during temporary transport loss
TCP is designed to withstand temporary loss of lower-level
connectivity. Such transient loss is not uncommon in mobile systems
(for example, due to handoffs, fade, etc.). The TCP connection
SHOULD be able to survive temporary lower-level loss when the IP
address of the client does not change (for example, short-duration
loss of the mobile device's traffic channel). Thus, the TCP/IP
stack on the client, the server, and any intermediate systems SHOULD
maintain the TCP connection during transient loss of connectivity.
Gellens [Page 3] Expires August 2006
Internet Draft Lemonade Deployment Considerations February 2006
5 Dormancy
Some mobile devices and networks support dormant mode, where the
traffic channel is brought down during idle periods, yet the PPP or
equivalent level remains active, and the mobile retains its IP
address. Maintenance of TCP connections during dormancy SHOULD be
supported by the client, server, and any intermediate systems.
6 Firewalls
One or more firewalls might exist in the path between the client and
server systems, as well as between the Message Submission and IMAP
servers. Proper deployment REQUIRES that TCP connections be
possible from the client system to the IMAP and Message Submission
ports on the servers, as well as from the Message Submission server
to the IMAP server. This may require configuring firewalls to
permit such usage.
Firewalls deployed in the network path MUST conform to [FIREWALLS].
Application proxies, which are a not uncommon mechanism, are
discussed in [PROXIES].
7 Security Considerations
There are numerous security considerations whenever an organization
chooses to make any of its services available via the Internet.
This includes email from mobile clients.
Sites concerned about email security should perform a threat
analysis, get relevant defenses and/or insurance in place and then
make a conscious decision to open up this service. Piggybacking
email traffic on the HTTP port in an attempt to avoid firewall
configuration explicitly permitting mobile email connections would
bypass this important step and reduces the overall security of the
system.
Organizations might wish to purchase a messaging server which comes
with some indemnity and/or a messaging server which is used "on the
edge" by the organization that sells the server.
This document does not attempt to catalogue either the various risks
an organization might face or the numerous techniques which can be
used to protect against the risks. However, to help illustrate the
deployment considerations, a very small sample of some of the risks
and countermeasures appear below.
Gellens [Page 4] Expires August 2006
Internet Draft Lemonade Deployment Considerations February 2006
Some organizations are concerned that permitting direct access to
their mail servers via the Internet increases their vulnerability,
since a successful exploit against a mail server can potentially
expose all mail and authentication credentials stored on that
server, and can serve as an injection point for spam. In addition,
there are concerns over eavesdropping or modification of mail data
and authentication credentials.
There exist a large number of approaches which can mitigate the
risks while allowing access to mail services via mobile clients.
Placing servers inside one or more DMZs can protect the rest of the
network from a compromised server. An additional way to reduce the
risk is to store authentication credentials on a system which is not
accessible from the Internet, and which the servers within the DMZ
can access only by sending the credentials as received from the
client and receiving an authorized/not authorized response. Many
additional techniques for further isolation exist, such as having
the DMZ IMAP server have no mail store of its own. When a client
connects to such a server, the DMZ IMAP server might contact the
authentication server and receive a ticket, which it passes to the
mail store in order to access the client's mail. In this way a
compromised IMAP server cannot be used to access the mail or
credentials for other users.
It is important to realize that simply throwing an extra box in
front of the mail servers, such as a gateway which may use HTTP or
any of a number of synchronization protocols to communicate with
clients, does not itself change the security aspects. By adding
such a gateway, the overall security of the system, and the
vulnerability of the mail servers, may remain unchanged or may be
significantly degraded. Isolation and indirection can be used to
protect against specific risks, but to be effective, such steps need
to be done after a threat analysis, and with understanding of the
issues involved.
Organizations SHOULD deploy servers which support the use of TLS for
all connections and which can be optionally configured to require
TLS. When TLS is used, it SHOULD be via the STARTTLS extensions
rather than the alternate port method. TLS can be an effective
measure to protect against specific threats, including eavesdropping
and alteration, of the traffic between the end-points. However,
just because TLS is deployed does not mean the system is "secure."
8 IANA Considerations
Gellens [Page 5] Expires August 2006
Internet Draft Lemonade Deployment Considerations February 2006
None.
9 Acknowledgments
Chris Newman suggested very helpful text.
10 Normative References
[IANA] <http://www.iana.org/assignments/port-numbers>
[PROFILE] draft-ietf-lemonade-profile
11 Informative References
[FIREWALLS] RFC 2979
[PROXIES] RFC 1919
12 Author's Address
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
randy@qualcomm.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
Gellens [Page 6] Expires August 2006
Internet Draft Lemonade Deployment Considerations February 2006
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gellens [Page 7] Expires August 2006