[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 5383

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


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/