idnits 2.17.1 draft-ietf-lemonade-deployments-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 297. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 274. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 281. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 285), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 33. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 83: '... [IANA] which MUST be available. IMAP uses port 143. Message...' RFC 2119 keyword, line 84: '...port 587. It is REQUIRED that the cli...' RFC 2119 keyword, line 86: '...s any intermediary systems, MUST allow...' RFC 2119 keyword, line 103: '... MUST be able to establish and main...' RFC 2119 keyword, line 104: '...ubmission server MUST be able to initi...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2005) is 7010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'KEYWORDS' is mentioned on line 67, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: Deployment Considerations for 3 lemonade-compliant Mobile Email R. Gellens 4 Document: draft-ietf-lemonade-deployments-00.txt Qualcomm 5 Expires: August 2006 February 2005 7 Deployment Considerations for lemonade-compliant Mobile Email 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt The list of 28 Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2006). All Rights Reserved. 35 Abstract 37 This document discusses deployment issues and describes implicit 38 requirements for successful deployment of mobile email based on the 39 IETF lemonade documents. 41 Gellens [Page 1] Expires August 2006 42 Table of Contents 44 1 Conventions Used in this Document . . . . . . . . . . . . . . 2 45 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 46 3 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 47 4 TCP Connections . . . . . . . . . . . . . . . . . . . . . . . 3 48 4.1 Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 3 49 4.2 Maintenance during temporary transport loss . . . . . . . 3 50 5 Dormancy . . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 6 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 7 Security Considerations . . . . . . . . . . . . . . . . . . . 4 53 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 54 9 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 55 10 Normative References . . . . . . . . . . . . . . . . . . . . . 6 56 11 Informative References . . . . . . . . . . . . . . . . . . . 6 57 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 58 Intellectual Property Statement . . . . . . . . . . . . . . . 6 59 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 7 61 1 Conventions Used in this Document 63 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 64 NOT", and "MAY" in this document are to be interpreted as described 65 in "Key words for use in RFCs to Indicate Requirement Levels" 66 [KEYWORDS]. 68 2 Introduction 70 The IETF lemonade group has developed a set of extensions to IMAP 71 and Message Submission, along with a profile document which 72 restricts server behavior and describes client usage [PROFILE]. 74 Successful deployment of lemonade-compliant mobile email requires 75 additional functionality, which is generally assumed and hence often 76 not covered in email RFCs. This document describes some of these 77 additional considerations, with a focus on those which have been 78 reported to be problematic. 80 3 Ports 82 Both IMAP and Message Submission have been assigned well-known ports 83 [IANA] which MUST be available. IMAP uses port 143. Message 84 Submission uses port 587. It is REQUIRED that the client be able to 85 contact the server on these ports. Hence the client and server 86 systems, as well as any intermediary systems, MUST allow 87 communication on these ports. 89 Gellens [Page 2] Expires August 2006 90 In addition to communications between the client and server systems, 91 lemonade forward-without-download requires that the Message 92 Submission server be able to establish a TCP connection to the IMAP 93 server. Unless specially configured, this uses port 143. 95 It should be noted that systems which don't support TCP on arbitrary 96 ports aren't full Internet clients. As a result, such systems must 97 use gateways to the Internet which necessarily result in data 98 integrity problems. 100 4 TCP Connections 102 Both IMAP and Message Submission use TCP. Hence the client system 103 MUST be able to establish and maintain TCP connections to these 104 servers. The Message Submission server MUST be able to initiate a 105 connection to the IMAP server. 107 4.1 Lifetime 109 The duration of the TCP connections between the client and server 110 systems for both IMAP and Message Submission can be arbitrarily 111 long. The client system, the server, as well as all intermediate 112 systems MUST NOT terminate these TCP connections simply because of 113 their duration. Both protocols do permit application-level timeouts 114 if no data is received within a period of time, under the control of 115 the server. However, it has been reported that some mobile carrier 116 network infrastructure elements impose time restrictions of their 117 own on TCP connections other than HTTP. Such behavior is harmful to 118 mobile email and all other TCP-based protocols. It is unclear how 119 widespread such reported behavior is, or if it is an accidental 120 consequence of an attempt at optimizing for HTTP traffic or a 121 deliberate choice. Either way, such a barrier to TCP connections is 122 a significant risk to the increasing usage of IETF protocols on 123 mobile networks. 125 4.2 Maintenance during temporary transport loss 127 TCP is designed to withstand temporary loss of lower-level 128 connectivity. Such transient loss is not uncommon in mobile systems 129 (for example, due to handoffs, fade, etc.). The TCP connection 130 SHOULD be able to survive temporary lower-level loss when the IP 131 address of the client does not change (for example, short-duration 132 loss of the mobile device's traffic channel). Thus, the TCP/IP 133 stack on the client, the server, and any intermediate systems SHOULD 134 maintain the TCP connection during transient loss of connectivity. 136 Gellens [Page 3] Expires August 2006 137 5 Dormancy 139 Some mobile devices and networks support dormant mode, where the 140 traffic channel is brought down during idle periods, yet the PPP or 141 equivalent level remains active, and the mobile retains its IP 142 address. Maintenance of TCP connections during dormancy SHOULD be 143 supported by the client, server, and any intermediate systems. 145 6 Firewalls 147 One or more firewalls might exist in the path between the client and 148 server systems, as well as between the Message Submission and IMAP 149 servers. Proper deployment REQUIRES that TCP connections be 150 possible from the client system to the IMAP and Message Submission 151 ports on the servers, as well as from the Message Submission server 152 to the IMAP server. This may require configuring firewalls to 153 permit such usage. 155 Firewalls deployed in the network path MUST conform to [FIREWALLS]. 157 Application proxies, which are a not uncommon mechanism, are 158 discussed in [PROXIES]. 160 7 Security Considerations 162 There are numerous security considerations whenever an organization 163 chooses to make any of its services available via the Internet. 164 This includes email from mobile clients. 166 Sites concerned about email security should perform a threat 167 analysis, get relevant defenses and/or insurance in place and then 168 make a conscious decision to open up this service. Piggybacking 169 email traffic on the HTTP port in an attempt to avoid firewall 170 configuration explicitly permitting mobile email connections would 171 bypass this important step and reduces the overall security of the 172 system. 174 Organizations might wish to purchase a messaging server which comes 175 with some indemnity and/or a messaging server which is used "on the 176 edge" by the organization that sells the server. 178 This document does not attempt to catalogue either the various risks 179 an organization might face or the numerous techniques which can be 180 used to protect against the risks. However, to help illustrate the 181 deployment considerations, a very small sample of some of the risks 182 and countermeasures appear below. 184 Gellens [Page 4] Expires August 2006 185 Some organizations are concerned that permitting direct access to 186 their mail servers via the Internet increases their vulnerability, 187 since a successful exploit against a mail server can potentially 188 expose all mail and authentication credentials stored on that 189 server, and can serve as an injection point for spam. In addition, 190 there are concerns over eavesdropping or modification of mail data 191 and authentication credentials. 193 There exist a large number of approaches which can mitigate the 194 risks while allowing access to mail services via mobile clients. 196 Placing servers inside one or more DMZs can protect the rest of the 197 network from a compromised server. An additional way to reduce the 198 risk is to store authentication credentials on a system which is not 199 accessible from the Internet, and which the servers within the DMZ 200 can access only by sending the credentials as received from the 201 client and receiving an authorized/not authorized response. Many 202 additional techniques for further isolation exist, such as having 203 the DMZ IMAP server have no mail store of its own. When a client 204 connects to such a server, the DMZ IMAP server might contact the 205 authentication server and receive a ticket, which it passes to the 206 mail store in order to access the client's mail. In this way a 207 compromised IMAP server cannot be used to access the mail or 208 credentials for other users. 210 It is important to realize that simply throwing an extra box in 211 front of the mail servers, such as a gateway which may use HTTP or 212 any of a number of synchronization protocols to communicate with 213 clients, does not itself change the security aspects. By adding 214 such a gateway, the overall security of the system, and the 215 vulnerability of the mail servers, may remain unchanged or may be 216 significantly degraded. Isolation and indirection can be used to 217 protect against specific risks, but to be effective, such steps need 218 to be done after a threat analysis, and with understanding of the 219 issues involved. 221 Organizations SHOULD deploy servers which support the use of TLS for 222 all connections and which can be optionally configured to require 223 TLS. When TLS is used, it SHOULD be via the STARTTLS extensions 224 rather than the alternate port method. TLS can be an effective 225 measure to protect against specific threats, including eavesdropping 226 and alteration, of the traffic between the end-points. However, 227 just because TLS is deployed does not mean the system is "secure." 229 8 IANA Considerations 231 Gellens [Page 5] Expires August 2006 232 None. 234 9 Acknowledgments 236 Chris Newman suggested very helpful text. 238 10 Normative References 240 [IANA] 242 [PROFILE] draft-ietf-lemonade-profile 244 11 Informative References 246 [FIREWALLS] RFC 2979 248 [PROXIES] RFC 1919 250 12 Author's Address 252 Randall Gellens 253 QUALCOMM Incorporated 254 5775 Morehouse Drive 255 San Diego, CA 92121 256 randy@qualcomm.com 258 Intellectual Property Statement 260 The IETF takes no position regarding the validity or scope of any 261 Intellectual Property Rights or other rights that might be claimed 262 to pertain to the implementation or use of the technology described 263 in this document or the extent to which any license under such 264 rights might or might not be available; nor does it represent that 265 it has made any independent effort to identify any such rights. 266 Information on the procedures with respect to rights in RFC 267 documents can be found in BCP 78 and BCP 79. 269 Copies of IPR disclosures made to the IETF Secretariat and any 270 assurances of licenses to be made available, or the result of an 271 attempt made to obtain a general license or permission for the use 272 of such proprietary rights by implementers or users of this 273 specification can be obtained from the IETF on-line IPR repository 274 at http://www.ietf.org/ipr. 276 Gellens [Page 6] Expires August 2006 277 The IETF invites any interested party to bring to its attention any 278 copyrights, patents or patent applications, or other proprietary 279 rights that may cover technology that may be required to implement 280 this standard. Please address the information to the IETF at 281 ietf-ipr@ietf.org. 283 Full Copyright Statement 285 Copyright (C) The Internet Society (2006). 287 This document is subject to the rights, licenses and restrictions 288 contained in BCP 78, and except as set forth therein, the authors 289 retain all their rights. 291 This document and the information contained herein are provided on 292 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 293 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 294 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 295 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 296 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 297 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 299 Gellens [Page 7] Expires August 2006