idnits 2.17.1 draft-ietf-lemonade-deployments-02.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 477. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 460. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 464), 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 85: '... [IANA] which MUST be available. IMAP uses port 143. Message...' RFC 2119 keyword, line 86: '...port 587. It is REQUIRED that the cli...' RFC 2119 keyword, line 90: '...s any intermediary systems, MUST allow...' RFC 2119 keyword, line 126: '... MUST be able to establish and main...' RFC 2119 keyword, line 127: '...ubmission server MUST be able to initi...' (16 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 (May 2006) is 6553 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'KEYWORDS' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' -- Obsolete informational reference (is this intentional?): RFC 4409 (ref. 'SUBMISSION') (Obsoleted by RFC 6409) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 10 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-02.txt Qualcomm 5 Expires: November 2006 May 2006 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 requirements 38 for successful deployment of mobile email which are implicit in the 39 IETF lemonade documents. 41 Gellens [Page 1] Expires November 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 . . . . . . 4 50 5 Dormancy . . . . . . . . . . . . . . . . . . . . . . . . . . 5 51 6 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 6.1 Firewall Traversal . . . . . . . . . . . . . . . . . . . 6 53 7 NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 54 8 Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 56 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 57 11 Normative References . . . . . . . . . . . . . . . . . . . . 9 58 12 Informative References . . . . . . . . . . . . . . . . . . . 9 59 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 60 Intellectual Property Statement . . . . . . . . . . . . . . . 10 61 Full Copyright Statement . . . . . . . . . . . . . . . . . . 10 63 1 Conventions Used in this Document 65 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 66 NOT", and "MAY" in this document are to be interpreted as described 67 in "Key words for use in RFCs to Indicate Requirement Levels" 68 [KEYWORDS]. 70 2 Introduction 72 The IETF lemonade group has developed a set of extensions to IMAP 73 and Message Submission, along with a profile document which 74 restricts server behavior and describes client usage [PROFILE]. 76 Successful deployment of lemonade-compliant mobile email requires 77 various functionality which is generally assumed and hence often not 78 covered in email RFCs. This document describes some of these 79 additional considerations, with a focus on those which have been 80 reported to be problematic. 82 3 Ports 84 Both IMAP and Message Submission have been assigned well-known ports 85 [IANA] which MUST be available. IMAP uses port 143. Message 86 Submission uses port 587. It is REQUIRED that the client be able to 87 contact the server on these ports. Hence the client and server 89 Gellens [Page 2] Expires November 2006 90 systems, as well as any intermediary systems, MUST allow 91 communication on these ports. 93 Historically, MUAs have used port 25 for message submission, and 94 [SUBMISSION] does accommodate this. However, it has become 95 increasingly common for ISPs and organizations to restrict outbound 96 port 25. Additionally, hotels and other public accommodations 97 sometimes intercept port 25 connections, regardless of the 98 destination host, resulting in users unexpectedly submitting 99 potentially sensitive communications to unknown and untrusted 100 third-party servers. Typically, users are not aware of such 101 interception. (Such interception violates [FIREWALLS] and has many 102 negative consequences.) 104 Due to endemic security vulnerabilities in widely-deployed SMTP 105 servers, organizations often employ application-level firewalls 106 which intercept SMTP and permit only a limited subset of the 107 protocol. New extensions are therefore difficult to deploy on port 108 25. Since lemonade requires support for several Submit extensions, 109 it is extremely important that lemonade clients use, and lemonade 110 servers listen on, port 587 by default. 112 In addition to communications between the client and server systems, 113 lemonade requires that the Message Submission server be able to 114 establish a TCP connection to the IMAP server (for 115 forward-without-download). Unless specially configured otherwise, 116 this uses port 143. 118 It should be noted that systems which don't support TCP on arbitrary 119 ports aren't full Internet clients. As a result, such systems use 120 gateways to the Internet which necessarily result in data integrity 121 problems. 123 4 TCP Connections 125 Both IMAP and Message Submission use TCP. Hence the client system 126 MUST be able to establish and maintain TCP connections to these 127 servers. The Message Submission server MUST be able to initiate a 128 connection to the IMAP server. 130 The requirements and advice in [HOST-REQUIREMENTS] SHOULD be 131 followed. 133 4.1 Lifetime 135 Gellens [Page 3] Expires November 2006 136 The duration of the TCP connections between the client and server 137 systems for both IMAP and Message Submission can be arbitrarily 138 long. The client system, the server, as well as all intermediate 139 systems MUST NOT terminate these TCP connections simply because of 140 their duration. 142 The only permissible timeouts on TCP connections occur at the IMAP 143 and Message Submission application level: if no data is received 144 within a period of time, either side MAY terminate the connection as 145 permitted by the protocol (see [SUBMISSION] or [PROFILE]). Such 146 timeouts MUST only be enforced by the server or client, not an 147 intermediary system. Since IMAP permits unsolicited notifications 148 of state changes, it is reasonable for clients to remain connected 149 for extended periods with no data being exchanged. 151 It has been reported that some mobile carrier network infrastructure 152 elements impose time restrictions of their own on TCP connections 153 other than HTTP. Such behavior is harmful to mobile email and all 154 other TCP-based protocols. It is unclear how widespread such 155 reported behavior is, or if it is an accidental consequence of an 156 attempt at optimizing for HTTP traffic or a deliberate choice. 157 Either way, such a barrier to TCP connections is a significant risk 158 to the increasing usage of IETF protocols on mobile networks. Note 159 that TCP is designed to be more efficient when it is used to 160 transfer data over time. Prohibiting such connections thus imposes 161 hidden costs on an operator's network, forcing clients to use TCP in 162 inefficient ways. 164 One way in which carriers can inadvertently force TCP connections 165 closed, resulting in users wasting packets by reopening them, is 166 described in Section 7. 168 4.2 Maintenance during temporary transport loss 170 TCP is designed to withstand temporary loss of lower-level 171 connectivity. Such transient loss is not uncommon in mobile systems 172 (for example, due to handoffs, fade, etc.). The TCP connection 173 SHOULD be able to survive temporary lower-level loss when the IP 174 address of the client does not change (for example, short-duration 175 loss of the mobile device's traffic channel or periods of high 176 packet loss). Thus, the TCP/IP stack on the client, the server, and 177 all intermediate systems SHOULD maintain the TCP connection during 178 transient loss of connectivity. 180 To this end, client and server systems SHOULD NOT set the TCP 181 keep-alive socket option, and SHOULD NOT close a connection based on 182 ICMP host unreachable messages. 184 Gellens [Page 4] Expires November 2006 185 5 Dormancy 187 Cellular data channels are connection-oriented (they are brought up 188 or down to establish or tear down connections); it costs network 189 resources to establish connections. 191 Some mobile devices and networks support dormant mode, in which the 192 traffic channel is brought down during idle periods, yet the PPP or 193 equivalent level remains active, and the mobile retains its IP 194 address. 196 Maintenance of TCP connections during dormancy SHOULD be supported 197 by the client, server, and any intermediate systems. Thus, as 198 stated in 4.2 above, client and server systems SHOULD NOT set the 199 TCP keep-alive socket option, and SHOULD NOT close a connection 200 based on ICMP host unreachable messages. 202 Sending packets just to keep the session active causes unnecessary 203 channel establishment and timeout; with a long-idle TCP connection, 204 this would periodically bring up the channel and then let it idle 205 until it times out, again and again. 207 6 Firewalls 209 New services must necessarily have their traffic pass through 210 firewalls in order to be usable by corporate employees or 211 organization members connecting externally, such as when using 212 mobile devices. Firewalls exist to block traffic, yet exceptions 213 must be made for services to be used. There is a body of best 214 practices based on long experience in this area. Numerous 215 techniques exist to help organizations balance protecting themselves 216 and providing services to their members, employees, and/or 217 customers. (Describing, or even enumerating, such techniques and 218 practices is beyond the scope of this document, but section 8 does 219 mention some.) 221 It is critical that protocol design and architecture permit such 222 practices, and not constrain them. One key way in which the design 223 of a new service can aid its secure deployment is to maintain the 224 one-to-one association of services and port numbers. 226 One or more firewalls might exist in the path between the client and 227 server systems, as well as between the Message Submission and IMAP 228 servers. Proper deployment REQUIRES that TCP connections be 229 possible from the client system to the IMAP and Message Submission 230 ports on the servers, as well as from the Message Submission server 231 to the IMAP server. This may require configuring firewalls to 232 permit such usage. 234 Gellens [Page 5] Expires November 2006 235 Firewalls deployed in the network path MUST conform to [FIREWALLS]. 237 Application proxies, which are a not uncommon mechanism, are 238 discussed in [PROXIES]. 240 6.1 Firewall Traversal 242 An often-heard complaint from those attempting to deploy new 243 services within an organization is that the group responsible for 244 maintaining the firewall is unable or unwilling to open the required 245 ports. The group which owns the firewall, being charged with 246 organizational network security, is often reluctant to open firewall 247 ports without an understanding of the benefits and the security 248 implications of the new service. 250 The group wishing to deploy a new service is often tempted to bypass 251 the procedure and internal politics necessary to open the firewall 252 ports. A tempting kludge is to tunnel the new service over an 253 existing service that is already permitted to pass through the 254 firewall, typically HTTP on port 80 or sometimes SMTP on port 25. 255 Some of the downsides to this are discussed in [KLUDGE]. 257 Such bypass can appear to be immediately successful, since the new 258 service seems to deploy. However, assuming the network security 259 group is competent, when they become aware of the kludge, their 260 response is generally to block the violation of organizational 261 security policy. It is difficult to design an application-level 262 proxy/firewall which can provide such access control without 263 violating the transparency requirements of firewalls, as described 264 in [FIREWALLS]. Collateral damage is common in these circumstances. 265 The new service (which initially appeared to have been successfully 266 deployed) as well as those existing services which were leveraged to 267 tunnel the new service, becomes subject to arbitrary and 268 unpredictable failures. This encourages an adversarial relationship 269 between the two groups, which hinders attempts at resolution. 271 Even more serious is what happens if a vulnerability is discovered 272 in the new service. Until the vulnerability is corrected, the 273 network security group must disable both the new service and the 274 (typically mission-critical) existing service on which it is 275 layered. 277 An often-repeated truism is that any computer which is connected to 278 a network is insecure. Security and usefulness are both 279 considerations, with organizations making choices about achieving 280 acceptable measures in both areas. Deploying new services typically 281 requires deciding to permit access to the ports used by the service, 282 with appropriate protections. While the delay necessary to review 283 the implications of a new service may be frustrating, in the long 285 Gellens [Page 6] Expires November 2006 286 run it is likely to be less expensive than a kludge. 288 7 NATs 290 Many NAT boxes place lifetime limits on state, which has the effect 291 of aging out long-idle TCP connections. Since memory is relatively 292 cheap, there's little benefit in arbitrary timeouts. Instead, the 293 oldest unused connection can be recycled if memory or other 294 resources (such as IP addresses) become exhausted, allowing 295 connections to stay stay up forever when resources are available. 297 Any NAT boxes which are deployed between client and server systems 298 SHOULD be configured to have extremely long connection lifetimes. 299 Unlimited lifetimes are RECOMMENDED. 301 Note that IMAP and message submission clients will automatically 302 re-open TCP connections as needed, but it saves time, packets, and 303 processing to avoid the need to do so. Re-opening IMAP and message 304 submission connections generally incurs costs for authentication, 305 TLS negotiation, and server processing, as well as resetting of TCP 306 behavior such as windows. It is also ridiculously wasteful to force 307 clients to send NOOP commands just to maintain NAT state, especially 308 since this can defeat dormancy mode. 310 8 Security Considerations 312 There are numerous security considerations whenever an organization 313 chooses to make any of its services available via the Internet. 314 This includes email from mobile clients. 316 Sites concerned about email security should perform a threat 317 analysis, get relevant defenses and/or insurance in place and then 318 make a conscious decision to open up this service. As discussed in 319 section 6.1, piggybacking email traffic on the HTTP port in an 320 attempt to avoid making a firewall configuration change to 321 explicitly permit mobile email connections would bypass this 322 important step and reduces the overall security of the system. 324 Organizations might wish to purchase a messaging server which comes 325 with some indemnity and/or a messaging server which is used "on the 326 edge" by the organization that sells the server. 328 This document does not attempt to catalogue either the various risks 329 an organization might face or the numerous techniques which can be 330 used to protect against the risks. However, to help illustrate the 331 deployment considerations, a very small sample of some of the risks 332 and countermeasures appear below. 334 Gellens [Page 7] Expires November 2006 335 Some organizations are concerned that permitting direct access to 336 their mail servers via the Internet increases their vulnerability, 337 since a successful exploit against a mail server can potentially 338 expose all mail and authentication credentials stored on that 339 server, and can serve as an injection point for spam. In addition, 340 there are concerns over eavesdropping or modification of mail data 341 and authentication credentials. 343 There exist a large number of approaches which can mitigate the 344 risks while allowing access to mail services via mobile clients. 346 Placing servers inside one or more DMZs can protect the rest of the 347 network from a compromised server. An additional way to reduce the 348 risk is to store authentication credentials on a system which is not 349 accessible from the Internet, and which the servers within the DMZ 350 can access only by sending the credentials as received from the 351 client and receiving an authorized/not authorized response. Such 352 isolation reduces the ability of a compromised server to serve as a 353 base for attacking other network hosts. 355 Many additional techniques for further isolation exist, such as 356 having the DMZ IMAP server have no mail store of its own. When a 357 client connects to such a server, the DMZ IMAP server might contact 358 the authentication server and receive a ticket, which it passes to 359 the mail store in order to access the client's mail. In this way a 360 compromised IMAP server cannot be used to access the mail or 361 credentials for other users. 363 It is important to realize that simply throwing an extra box in 364 front of the mail servers, such as a gateway which may use HTTP or 365 any of a number of synchronization protocols to communicate with 366 clients, does not itself change the security aspects. By adding 367 such a gateway, the overall security of the system, and the 368 vulnerability of the mail servers, may remain unchanged or may be 369 significantly worsened. Isolation and indirection can be used to 370 protect against specific risks, but to be effective, such steps need 371 to be done after a threat analysis, and with understanding of the 372 issues involved. 374 Organizations SHOULD deploy servers which support the use of TLS for 375 all connections and which can be optionally configured to require 376 TLS. When TLS is used, it SHOULD be via the STARTTLS extensions 377 rather than the alternate port method. TLS can be an effective 378 measure to protect against specific threats, including eavesdropping 379 and alteration, of the traffic between the end-points. However, 380 just because TLS is deployed does not mean the system is "secure." 382 Gellens [Page 8] Expires November 2006 383 Attempts at bypassing current firewall policy when deploying new 384 services have serious risks, as discussed in section 6.1. 386 It's rare for a new service to not have associated security 387 considerations. Making email available to an organization's members 388 using mobile devices can offer significant benefits. 390 9 IANA Considerations 392 None. 394 10 Acknowledgments 396 Chris Newman and Phil Karn suggested very helpful text. Brian Ross 397 and Dave Cridland reviewed drafts and provided excellent 398 suggestions. 400 11 Normative References 402 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement 403 Levels", S. Bradner, BCP 14, March 1997. 405 [IANA] IANA Port Number Registry, 406 408 [PROFILE] "LEMONADE profile bis", S. Maes, A. Melnikov, D. Cridland, 409 editors, draft-ietf-lemonade-profile, work in progress. 411 12 Informative References 413 [FIREWALLS] "Behavior of and Requirements for Internet Firewalls", 414 N. Freed, RFC 2979, October 2000. 416 [HOST-REQUIREMENTS] "Requirements for Internet Hosts -- 417 Communication Layers", R. Braden, RFC 1122, October 1989. 419 [KLUDGE] "On the use of HTTP as a Substrate", K. Moore, BCP 56, 420 February 2002. 422 [PROXIES] "Classical versus Transparent IP Proxies", M. Chatel, RFC 423 1919, March 1996. 425 Gellens [Page 9] Expires November 2006 427 [SUBMISSION] "Message Submission for Mail", R. Gellens, J. Klensin, 428 RFC 4409, April 2006. 430 13 Author's Address 432 Randall Gellens 433 QUALCOMM Incorporated 434 5775 Morehouse Drive 435 San Diego, CA 92121 436 randy@qualcomm.com 438 Intellectual Property Statement 440 The IETF takes no position regarding the validity or scope of any 441 Intellectual Property Rights or other rights that might be claimed 442 to pertain to the implementation or use of the technology described 443 in this document or the extent to which any license under such 444 rights might or might not be available; nor does it represent that 445 it has made any independent effort to identify any such rights. 446 Information on the procedures with respect to rights in RFC 447 documents can be found in BCP 78 and BCP 79. 449 Copies of IPR disclosures made to the IETF Secretariat and any 450 assurances of licenses to be made available, or the result of an 451 attempt made to obtain a general license or permission for the use 452 of such proprietary rights by implementers or users of this 453 specification can be obtained from the IETF on-line IPR repository 454 at http://www.ietf.org/ipr. 456 The IETF invites any interested party to bring to its attention any 457 copyrights, patents or patent applications, or other proprietary 458 rights that may cover technology that may be required to implement 459 this standard. Please address the information to the IETF at 460 ietf-ipr@ietf.org. 462 Full Copyright Statement 464 Copyright (C) The Internet Society (2006). 466 This document is subject to the rights, licenses and restrictions 467 contained in BCP 78, and except as set forth therein, the authors 468 retain all their rights. 470 Gellens [Page 10] Expires November 2006 471 This document and the information contained herein are provided on 472 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 473 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 474 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 475 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 476 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 477 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 479 Gellens [Page 11] Expires November 2006