doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc5383.txt b/doc/rfc/rfc5383.txt
new file mode 100644
index 0000000..586ce38
--- /dev/null
+++ b/doc/rfc/rfc5383.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                         R. Gellens
+Request for Comments: 5383                                      Qualcomm
+BCP: 143                                                    October 2008
+Category: Best Current Practice
+
+
+     Deployment Considerations for Lemonade-Compliant Mobile Email
+
+Status of This Memo
+
+   This document specifies an Internet Best Current Practices for the
+   Internet Community, and requests discussion and suggestions for
+   improvements.  Distribution of this memo is unlimited.
+
+
+Abstract
+
+   This document discusses deployment issues and describes requirements
+   for successful deployment of mobile email that are implicit in the
+   IETF lemonade documents.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Conventions Used in This Document ...............................2
+   3. Ports ...........................................................2
+   4. TCP Connections .................................................3
+      4.1. Lifetime ...................................................4
+      4.2. Maintenance during Temporary Transport Loss ................5
+   5. Dormancy ........................................................6
+   6. Firewalls .......................................................6
+      6.1. Firewall Traversal .........................................7
+   7. NATs ............................................................8
+   8. Security Considerations .........................................8
+   9. Acknowledgments ................................................10
+   10. Normative References ..........................................10
+   11. Informative References ........................................10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens                  Best Current Practice                  [Page 1]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+1.  Introduction
+
+   The IETF lemonade group has developed a set of extensions to IMAP and
+   Message Submission, along with a profile document that restricts
+   server behavior and describes client usage [PROFILE].
+
+   Successful deployment of lemonade-compliant mobile email requires
+   various functionality that is generally assumed and hence not often
+   covered in email RFCs.  This document describes some of these
+   additional considerations, with a focus on those that have been
+   reported to be problematic.
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [KEYWORDS].
+
+3.  Ports
+
+   Both IMAP and Message Submission have been assigned well-known ports
+   [IANA] that 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.
+
+   Historically, Message User Agents (MUAs) have used port 25 for
+   Message Submission, and [SUBMISSION] does accommodate this.  However,
+   it has become increasingly common for ISPs and organizations to
+   restrict outbound port 25.  Additionally, hotels and other public
+   accommodations sometimes intercept port 25 connections, regardless of
+   the destination host, resulting in users unexpectedly submitting
+   potentially sensitive communications to unknown and untrusted third-
+   party servers.  Typically, users are not aware of such interception.
+   (Such interception violates [FIREWALLS] and has many negative
+   consequences.)
+
+   Due to endemic security vulnerabilities in widely deployed SMTP
+   servers, organizations often employ application-level firewalls that
+   intercept SMTP and permit only a limited subset of the protocol.  New
+   extensions are therefore more difficult to deploy on port 25.  Since
+   lemonade requires support for several [SUBMISSION] extensions, it is
+   extremely important that lemonade clients use, and lemonade servers
+   listen on, port 587 by default.
+
+
+
+
+
+
+Gellens                  Best Current Practice                  [Page 2]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+   In addition to communications between the client and server systems,
+   lemonade requires that the Message Submission server be able to
+   establish a TCP connection to the IMAP server (for forward-without-
+   download).  This uses port 143 by default.
+
+   Messaging clients sometimes use protocols to store, retrieve, and
+   update configuration and preference data.  Functionality such as
+   setting a new device to use the configuration and preference data of
+   another device, or having a device inherit default configuration data
+   from a user account, an organization, or other source, is likely to
+   be even more useful with small mobile devices.  Various protocols can
+   be used for configuration and preference data; most of these
+   protocols have designated ports.  It is important that clients be
+   able to contact such servers on the appropriate ports.  As an
+   example, one protocol that can be used for this purpose is [ACAP], in
+   which case port 674 needs to be available.
+
+   Note that systems that do not support application use of [TCP] on
+   arbitrary ports are not full Internet clients.  As a result, such
+   systems use gateways to the Internet that 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.  Support for application use of [TCP]
+   is REQUIRED of both client and server systems.
+
+   The requirements and advice in [HOST-REQUIREMENTS] SHOULD be
+   followed.
+
+   Note that, for environments that do not support application use of
+   [TCP] but do so for HTTP, email can be offered by deploying webmail.
+   Webmail is a common term for email over the web, where a server
+   speaks HTTP to the client and an email protocol (often IMAP) to the
+   mail store.  Its functionality is necessarily limited by the
+   capabilities of the web client, the webmail server, the protocols
+   used between the webmail server and the client (HTTP and a markup
+   language such as HTML), and between the webmail server and the mail
+   store.  However, if HTTP is all that is available to an application,
+   the environment is by definition limited and thus, functionality
+   offered to the user must also be limited, and can't be lemonade
+   compliant.
+
+
+
+
+
+
+Gellens                  Best Current Practice                  [Page 3]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+4.1.  Lifetime
+
+   In this document, "idle" refers to the idle time, as in the
+   "established connection idle-timeout" of [BEHAVE-TCP], while
+   "duration" refers to the total time that a TCP connection has been
+   established.
+
+   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 (that is, just because of how long they have been open).
+
+   Lemonade depends on idle timers being enforced only at the
+   application level (IMAP and Message Submission): if no data is
+   received within a period of time, either side MAY terminate the
+   connection as permitted by the protocol (see [SUBMISSION] or [IMAP]).
+   Since IMAP permits unsolicited notifications of state changes, it is
+   reasonable for clients to remain connected for extended periods with
+   no data being exchanged.  Being forced to send data just to keep the
+   connection alive can prevent or hinder optimizations such as dormancy
+   mode (see Section 5).
+
+   Two hours is a fairly common configuration timeout at middleboxes.
+   That is, there are a number of sites at which TCP connections are
+   torn down by the network two hours after data was last sent in either
+   direction (for example, REQ-5 in [BEHAVE-TCP]).  Thus, lemonade
+   clients and servers SHOULD make sure that, in the absence of a
+   specific configuration setting that specifies a longer maximum idle
+   interval, the TCP connection does not remain idle for two hours.
+   This rule ensures that, by default, lemonade clients and servers
+   operate in environments configured with a two-hour maximum for idle
+   TCP connections.  Network and server operators can still permit IMAP
+   connections to remain idle in excess of two hours and thus increase
+   the benefits of dormancy, by configuring lemonade clients and
+   servers, and network equipment, to allow this.
+
+   It has been reported that some networks impose duration time
+   restrictions of their own on TCP connections other than HTTP.  Such
+   behavior is harmful to 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,
+   implementation limitations in firewalls, NATs, or other devices, or a
+   deliberate choice.  In any case, such a barrier to TCP connections is
+   a significant risk to the increasing usage of IETF protocols on such
+   networks.  Note that TCP is designed to be more efficient when it is
+
+
+
+
+
+Gellens                  Best Current Practice                  [Page 4]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+   used to transfer data over time.  Prohibiting such connections thus
+   imposes hidden costs on an operator's network, forcing clients to use
+   TCP in inefficient ways.  One way in which carriers can inadvertently
+   force TCP connections closed, resulting in users wasting packets by
+   reopening them, is described in Section 7.
+
+   Note that systems remain able to terminate TCP connections at any
+   time based on local decisions, for example, to prevent overload
+   during a denial-of-service attack.  These mechanisms are permitted to
+   take idle time into consideration and are not affected by these
+   requirements.
+
+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 or periods of high packet
+   loss).  Thus, the TCP/IP stack on the client, the server, and all
+   intermediate systems SHOULD maintain the TCP connection during
+   transient loss of connectivity.
+
+   In general, applications can choose whether or not to enable TCP
+   keep-alives, but in many cases are unable to affect any other aspect
+   of TCP keep-alive operation, such as time between keep-alive packets,
+   number of packets sent before the connection is aborted, etc.  In
+   some environments, these are operating system tuning parameters not
+   under application control.  In some cases, operational difficulties
+   have been reported with application use of the TCP keep-alive option,
+   which might be the result of TCP implementation differences or
+   defects specific to a platform.  Lemonade client and server systems
+   SHOULD NOT set the TCP keep-alive socket option unless operating in
+   environments where this works correctly and such packets will not be
+   sent more frequently than every two hours.  Application-level keep-
+   alives (such as IMAP NOOP) MAY be used instead of the TCP keep-alive
+   option.
+
+   Client, server, and intermediate systems MUST comply with the
+   "Destination Unreachable -- codes 0, 1, 5" text in Section 4.2.3.9 of
+   [HOST-REQUIREMENTS], which states "Since these Unreachable messages
+   indicate soft error conditions, TCP MUST NOT abort the connection".
+
+
+
+
+
+
+
+
+Gellens                  Best Current Practice                  [Page 5]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+5.  Dormancy
+
+   Cellular data channels are connection-oriented (they are brought up
+   or down to establish or tear down connections); it costs network
+   resources to establish connections.  Generally speaking, mobile
+   device battery charges last longer when the traffic channel is used
+   less.
+
+   Some mobile devices and networks support dormant mode, in which 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, as described in
+   Sections 4.1 and 4.2.
+
+   Sending packets just to keep the session active causes unnecessary
+   channel establishment and timeout; with a long-idle TCP connection,
+   this would periodically bring up the channel and then let it idle
+   until it times out, again and again.  However, in the absence of
+   specific configuration information to the contrary, it is necessary
+   to do this to ensure correct operation by default.
+
+6.  Firewalls
+
+   New services must necessarily have their traffic pass through
+   firewalls in order to be usable by corporate employees or
+   organization members connecting externally, such as when using mobile
+   devices.  Firewalls exist to block traffic, yet exceptions must be
+   made for services to be used.  There is a body of best practices
+   based on long experience in this area.  Numerous techniques exist to
+   help organizations balance protecting themselves and providing
+   services to their members, employees, and/or customers. (Describing,
+   or even enumerating, such techniques and practices is beyond the
+   scope of this document, but Section 8 does mention some.)
+
+   It is critical that protocol design and architecture permit such
+   practices, and not constrain them.  One key way in which the design
+   of a new service can aid its secure deployment is to maintain the
+   one-to-one association of services and port numbers.
+
+
+
+
+
+
+
+
+
+
+Gellens                  Best Current Practice                  [Page 6]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+   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 NOT damage protocol
+   traffic.  In particular, both Message Submission and IMAP connections
+   from the client MUST be permitted.  Firewalls MUST NOT partially
+   block extensions to these protocols, such as by allowing one side of
+   an extension negotiation, as doing so results in the two sides being
+   out of synch, with later failures.  See [FIREWALLS] for more
+   discussion.
+
+   Application proxies, which are not uncommon mechanisms, are discussed
+   in [PROXIES].
+
+6.1.  Firewall Traversal
+
+   An often-heard complaint from those attempting to deploy new services
+   within an organization is that the group responsible for maintaining
+   the firewall is unable or unwilling to open the required ports.  The
+   group that owns the firewall, being charged with organizational
+   network security, is often reluctant to open firewall ports without
+   an understanding of the benefits and the security implications of the
+   new service.
+
+   The group wishing to deploy a new service is often tempted to bypass
+   the procedure and internal politics necessary to open the firewall
+   ports.  A tempting kludge is to tunnel the new service over an
+   existing service that is already permitted to pass through the
+   firewall, typically HTTP on port 80 or sometimes SMTP on port 25.
+   Some of the downsides to this are discussed in [KLUDGE].
+
+   Such a bypass can appear to be immediately successful, since the new
+   service seems to deploy.  However, assuming the network security
+   group is competent, when they become aware of the kludge, their
+   response is generally to block the violation of organizational
+   security policy.  It is difficult to design an application-level
+   proxy/firewall that can provide such access control without violating
+   the transparency requirements of firewalls, as described in
+   [FIREWALLS].  Collateral damage is common in these circumstances.
+   The new service (which initially appeared to have been successfully
+   deployed) as well as those existing services that were leveraged to
+   tunnel the new service, become subject to arbitrary and unpredictable
+
+
+
+
+Gellens                  Best Current Practice                  [Page 7]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+   failures.  This encourages an adversarial relationship between the
+   two groups, which hinders attempts at resolution.
+
+   Even more serious is what happens if a vulnerability is discovered in
+   the new service.  Until the vulnerability is corrected, the network
+   security group must disable both the new service and the (typically
+   mission-critical) existing service on which it is layered.
+
+   An often-repeated truism is that any computer that is connected to a
+   network is insecure.  Security and usefulness are both
+   considerations, with organizations making choices about achieving
+   acceptable measures in both areas.  Deploying new services typically
+   requires deciding to permit access to the ports used by the service,
+   with appropriate protections.  While the delay necessary to review
+   the implications of a new service may be frustrating, in the long
+   run, it is likely to be less expensive than a kludge.
+
+7.  NATs
+
+   Any NAT boxes that are deployed between client and server systems
+   MUST comply with REQ-5 in [BEHAVE-TCP], which requires that "the
+   value of the 'established connection idle-timeout' MUST NOT be less
+   than 2 hours 4 minutes".
+
+   See Section 5 for additional information on connection lifetimes.
+
+   Note that IMAP and Message Submission clients will automatically re-
+   open TCP connections as needed, but it saves time, packets, and
+   processing to avoid the need to do so.  Re-opening IMAP and Message
+   Submission connections generally incurs costs for authentication,
+   Transport Layer Security (TLS) negotiation, and server processing, as
+   well as resetting of TCP behavior, such as windows.  It is also
+   wasteful to force clients to send NOOP commands just to maintain NAT
+   state, especially since this can defeat dormancy mode.
+
+8.  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 protections in place, and then make a
+   conscious decision to open up this service.  As discussed in Section
+   6.1, piggybacking email traffic on the HTTP port in an attempt to
+   avoid making a firewall configuration change to explicitly permit
+   mobile email connections would bypass this important step and reduce
+   the overall security of the system.
+
+
+
+Gellens                  Best Current Practice                  [Page 8]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+   Organizations deploying a messaging server "on the edge" (that is,
+   accessible from the open Internet) are encouraged to choose one that
+   has been designed to operate in that environment.
+
+   This document does not attempt to catalogue either the various risks
+   an organization might face or the numerous techniques that 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.
+
+   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.
+
+   A large number of approaches exist that can mitigate the risks while
+   allowing access to mail services via mobile clients.
+
+   Placing servers inside one or more DMZs (demilitarized zones, also
+   called perimeter networks) 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 that is not accessible from
+   the Internet and that the servers within the DMZ can access only by
+   sending the credentials as received from the client and receiving an
+   authorized/not authorized response.  Such isolation reduces the
+   ability of a compromised server to serve as a base for attacking
+   other network hosts.
+
+   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 that 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 worsened.
+   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 an understanding of the issues involved.
+
+
+
+Gellens                  Best Current Practice                  [Page 9]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+   Organizations SHOULD deploy servers that support the use of TLS for
+   all connections and that 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 endpoints.  However, just
+   because TLS is deployed does not mean the system is "secure".
+
+   Attempts at bypassing current firewall policy when deploying new
+   services have serious risks, as discussed in Section 6.1.
+
+   It's rare for a new service to not have associated security
+   considerations.  Making email available to an organization's members
+   using mobile devices can offer significant benefits.
+
+9.  Acknowledgments
+
+   Chris Newman and Phil Karn suggested very helpful text.  Brian Ross
+   and Dave Cridland reviewed drafts and provided excellent suggestions.
+
+10.  Normative References
+
+   [BEHAVE-TCP]        Guha, S., Ed., Biswas, K., Ford, B., Sivakumar,
+                       S., and P. Srisuresh, "NAT Behavioral
+                       Requirements for TCP", BCP 142, RFC 5382, October
+                       2008.
+
+   [HOST-REQUIREMENTS] Braden, R., Ed., "Requirements for Internet Hosts
+                       - Communication Layers", STD 3, RFC 1122, October
+                       1989.
+
+   [KEYWORDS]          Bradner, S., "Key words for use in RFCs to
+                       Indicate Requirement Levels", BCP 14, RFC 2119,
+                       March 1997.
+
+   [IANA]              IANA Port Number Registry,
+                       <http://www.iana.org/assignments/port-numbers>
+
+   [TCP]               Postel, J., "Transmission Control Protocol", STD
+                       7, RFC 793, September 1981.
+
+11.  Informative References
+
+   [ACAP]              Newman, C. and J. Myers, "ACAP -- Application
+                       Configuration Access Protocol", RFC 2244,
+                       November 1997.
+
+
+
+
+
+Gellens                  Best Current Practice                 [Page 10]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+   [FIREWALLS]         Freed, N., "Behavior of and Requirements for
+                       Internet Firewalls", RFC 2979, October 2000.
+
+   [IMAP]              Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
+                       VERSION 4rev1", RFC 3501, March 2003.
+
+   [KLUDGE]            Moore, K., "On the use of HTTP as a Substrate",
+                       BCP 56, RFC 3205, February 2002.
+
+   [PROFILE]           Maes, S. and A. Melnikov, "Internet Email to
+                       Support Diverse Service Environments (Lemonade)
+                       Profile", RFC 4550, June 2006.
+
+   [PROXIES]           Chatel, M., "Classical versus Transparent IP
+                       Proxies", RFC 1919, March 1996.
+
+   [SUBMISSION]        Gellens, R. and J. Klensin, "Message Submission
+                       for Mail", RFC 4409, April 2006.
+
+Author's Address
+
+   Randall Gellens
+   QUALCOMM Incorporated
+   5775 Morehouse Drive
+   San Diego, CA  92121
+
+   EMail: randy@qualcomm.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens                  Best Current Practice                 [Page 11]
+
+RFC 5383           Lemonade Deployment Considerations       October 2008
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2008).
+
+   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, THE IETF TRUST 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.
+
+Intellectual Property
+
+   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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Gellens                  Best Current Practice                 [Page 12]
+