idnits 2.17.1 draft-ietf-lemonade-deployments-09.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 13. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 624. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (June 2007) is 6159 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) == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3501 (ref. 'IMAP') (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 4550 (ref. 'PROFILE') (Obsoleted by RFC 5550) -- Obsolete informational reference (is this intentional?): RFC 4409 (ref. 'SUBMISSION') (Obsoleted by RFC 6409) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft: Deployment Considerations for 2 lemonade-compliant Mobile Email R. Gellens 3 Document: draft-ietf-lemonade-deployments-09.txt Qualcomm 4 Expires: December 2007 June 2007 6 Deployment Considerations for lemonade-compliant Mobile Email 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt The list of 27 Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The IETF Trust (2007). All Rights Reserved. 34 Abstract 36 This document discusses deployment issues and describes requirements 37 for successful deployment of mobile email which are implicit in the 38 IETF lemonade documents. 40 Gellens [Page 1] Expires November 2007 41 Table of Contents 43 1 Conventions Used in this Document . . . . . . . . . . . . . . 2 44 2 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 45 3 Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 46 4 TCP Connections . . . . . . . . . . . . . . . . . . . . . . 3 47 4.1 Lifetime . . . . . . . . . . . . . . . . . . . . . . . . 4 48 4.2 Maintenance during temporary transport loss . . . . . . 5 49 5 Dormancy . . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 6 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 6.1 Firewall Traversal . . . . . . . . . . . . . . . . . . . 7 52 7 NATs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 8 Security Considerations . . . . . . . . . . . . . . . . . . . 9 54 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 55 10 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 56 11 Normative References . . . . . . . . . . . . . . . . . . . . 11 57 12 Informative References . . . . . . . . . . . . . . . . . . . 11 58 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 59 Appendix A: Changes from Previous Version . . . . . . . . . . 12 60 Intellectual Property Statement . . . . . . . . . . . . . . . 13 61 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 63 1 Conventions Used in this Document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [KEYWORDS]. 69 2 Introduction 71 The IETF lemonade group has developed a set of extensions to IMAP 72 and Message Submission, along with a profile document which 73 restricts server behavior and describes client usage [PROFILE]. 75 Successful deployment of lemonade-compliant mobile email requires 76 various functionality which is generally assumed and hence often not 77 covered in email RFCs. This document describes some of these 78 additional considerations, with a focus on those which have been 79 reported to be problematic. 81 3 Ports 83 Both IMAP and Message Submission have been assigned well-known ports 84 [IANA] which MUST be available. IMAP uses port 143. Message 85 Submission uses port 587. It is REQUIRED that the client be able to 86 contact the server on these ports. Hence the client and server 88 Gellens [Page 2] Expires November 2007 89 systems, as well as any intermediary systems, MUST allow 90 communication on these ports. 92 Historically, MUAs have used port 25 for message submission, and 93 [SUBMISSION] does accommodate this. However, it has become 94 increasingly common for ISPs and organizations to restrict outbound 95 port 25. Additionally, hotels and other public accommodations 96 sometimes intercept port 25 connections, regardless of the 97 destination host, resulting in users unexpectedly submitting 98 potentially sensitive communications to unknown and untrusted 99 third-party servers. Typically, users are not aware of such 100 interception. (Such interception violates [FIREWALLS] and has many 101 negative consequences.) 103 Due to endemic security vulnerabilities in widely-deployed SMTP 104 servers, organizations often employ application-level firewalls 105 which intercept SMTP and permit only a limited subset of the 106 protocol. New extensions are therefore more difficult to deploy on 107 port 25. Since lemonade requires support for several [SUBMISSION] 108 extensions, it is extremely important that lemonade clients use, and 109 lemonade servers listen on, port 587 by default. 111 In addition to communications between the client and server systems, 112 lemonade requires that the Message Submission server be able to 113 establish a TCP connection to the IMAP server (for 114 forward-without-download). This uses port 143 by default. 116 Messaging clients sometimes use protocols to store, retrieve, and 117 update configuration and preference data. Functionality such as 118 setting a new device to use the configuration and preference data of 119 another device, or having a device inherit default configuration 120 data from a user account, an organization, or other source, is 121 likely to be even more useful with small mobile devices. Various 122 protocols can be used for configuration and preference data; most of 123 these protocols have designated ports. It is important that clients 124 be able to contact such servers on the appropriate ports. As an 125 example, one protocol that can be used for this purpose is [ACAP], 126 in which case port 674 needs to be available. 128 Note that systems which do not support application use of [TCP] on 129 arbitrary ports are not full Internet clients. As a result, such 130 systems use gateways to the Internet which necessarily result in 131 data integrity problems. 133 4 TCP Connections 135 Gellens [Page 3] Expires November 2007 136 Both IMAP and Message Submission use [TCP]. Hence the client system 137 MUST be able to establish and maintain TCP connections to these 138 servers. The Message Submission server MUST be able to initiate a 139 connection to the IMAP server. Support for application use of [TCP] 140 is REQUIRED of both client and server systems. 142 The requirements and advice in [HOST-REQUIREMENTS] SHOULD be 143 followed. 145 Note that, for environments that do not support application use of 146 [TCP] but do so for HTTP, email can be offered by deploying webmail. 147 Webmail is a common term for email over the web, where a server 148 speaks HTTP to the client and an email protocol (often IMAP) to the 149 mail store. Its functionality is necessarily limited by the 150 capabilities of the web client, the webmail server, the protocols 151 used between the webmail server and the client (HTTP and a markup 152 language such as HTML), and between the webmail server and the mail 153 store. However, if HTTP is all that is available to an application, 154 the environment is by definition limited and thus functionality 155 offered to the user must also be limited, and can't be lemonade 156 compliant. 158 4.1 Lifetime 160 In this document, "idle" refers to the idle time, as in the 161 "established connection idle-timeout" of [BEHAVE-TCP], while 162 "duration" refers to the total time that a TCP connection has been 163 established. 165 The duration of the TCP connections between the client and server 166 systems for both IMAP and Message Submission can be arbitrarily 167 long. The client system, the server, as well as all intermediate 168 systems MUST NOT terminate these TCP connections simply because of 169 their duration (that is, just because of how long they have been 170 open). 172 Lemonade depends on idle timers being enforced only at the 173 application level (IMAP and Message Submission): if no data is 174 received within a period of time, either side MAY terminate the 175 connection as permitted by the protocol (see [SUBMISSION] or 176 [IMAP]). Since IMAP permits unsolicited notifications of state 177 changes, it is reasonable for clients to remain connected for 178 extended periods with no data being exchanged. Being forced to send 179 data just to keep the connection alive can prevent or hinder 180 optimizations such as dormancy mode (see section 5). 182 Gellens [Page 4] Expires November 2007 183 Two hours is a fairly common configuration timeout at middleboxes. 184 That is, there are a number of sites at which TCP connections are 185 torn down by the network two hours after data was last sent in 186 either direction (for example, REQ-5 in [BEHAVE-TCP]). Thus, 187 lemonade clients and servers SHOULD make sure that, in the absence 188 of specific configuration otherwise, the TCP connection not remain 189 idle for two hours. This rule ensures that, by default, lemonade 190 clients and servers operate in environments configured with a 191 two-hour maximum for idle TCP connections. Network and server 192 operators can still permit IMAP connections to remain idle in excess 193 of two hours and thus increase the benefits of dormancy, by 194 configuring lemonade clients and servers, and network equipment, to 195 allow this. 197 It has been reported that some networks impose duration time 198 restrictions of their own on TCP connections other than HTTP. Such 199 behavior is harmful to email and all other TCP-based protocols. It 200 is unclear how widespread such reported behavior is, or if it is an 201 accidental consequence of an attempt at optimizing for HTTP traffic, 202 implementation limitations in firewalls, NATs or other devices, or a 203 deliberate choice. Either way, such a barrier to TCP connections is 204 a significant risk to the increasing usage of IETF protocols on such 205 networks. Note that TCP is designed to be more efficient when it is 206 used to transfer data over time. Prohibiting such connections thus 207 imposes hidden costs on an operator's network, forcing clients to 208 use TCP in inefficient ways. One way in which carriers can 209 inadvertently force TCP connections closed, resulting in users 210 wasting packets by reopening them, is described in Section 7 212 Note that systems remain able to terminate TCP connections at any 213 time based on local decisions, for example, to prevent overload 214 during a denial-of-service attack. These mechanisms are permitted 215 to take idle time into consideration and are not affected by these 216 requirements. 218 4.2 Maintenance during temporary transport loss 220 TCP is designed to withstand temporary loss of lower-level 221 connectivity. Such transient loss is not uncommon in mobile systems 222 (for example, due to handoffs, fade, etc.). The TCP connection 223 SHOULD be able to survive temporary lower-level loss when the IP 224 address of the client does not change (for example, short-duration 225 loss of the mobile device's traffic channel or periods of high 226 packet loss). Thus, the TCP/IP stack on the client, the server, and 227 all intermediate systems SHOULD maintain the TCP connection during 228 transient loss of connectivity. 230 Gellens [Page 5] Expires November 2007 231 In general, applications can choose to enable TCP keep-alives or 232 not, but in many cases are unable to affect any other aspect of TCP 233 keep-alive operation, such as time between keep-alive packets, 234 number of packets sent before the connection is aborted, etc. In 235 some environments these are operating system tuning parameters not 236 under application control. In some cases, operational difficulties 237 have been reported with application use of the TCP keep-alive 238 option, which might be the result of TCP implementation differences 239 or defects specific to a platform. Lemonade client and server 240 systems SHOULD NOT set the TCP keep-alive socket option unless 241 operating in environments where this works correctly and such 242 packets will not be sent more frequently than every two hours. 243 Application-level keep-alives (such as IMAP NOOP) MAY be used 244 instead of the TCP keep-alive option. 246 Client, server, and intermediate systems MUST comply with the 247 "Destination Unreachable -- codes 0, 1, 5" text in Section 4.2.3.9 248 of [HOST-REQUIREMENTS], which states "Since these Unreachable 249 messages indicate soft error conditions, TCP MUST NOT abort the 250 connection." 252 5 Dormancy 254 Cellular data channels are connection-oriented (they are brought up 255 or down to establish or tear down connections); it costs network 256 resources to establish connections. Generally speaking, mobile 257 device battery charges last longer when the traffic channel is used 258 less. 260 Some mobile devices and networks support dormant mode, in which the 261 traffic channel is brought down during idle periods, yet the PPP or 262 equivalent level remains active, and the mobile retains its IP 263 address. 265 Maintenance of TCP connections during dormancy SHOULD be supported 266 by the client, server, and any intermediate systems, as described in 267 Sections 4.1 and 4.2. 269 Sending packets just to keep the session active causes unnecessary 270 channel establishment and timeout; with a long-idle TCP connection, 271 this would periodically bring up the channel and then let it idle 272 until it times out, again and again. However, in the absence of 273 specific configuration information to the contrary, it is necessary 274 to do this to ensure correct operation by default. 276 Gellens [Page 6] Expires November 2007 277 6 Firewalls 279 New services must necessarily have their traffic pass through 280 firewalls in order to be usable by corporate employees or 281 organization members connecting externally, such as when using 282 mobile devices. Firewalls exist to block traffic, yet exceptions 283 must be made for services to be used. There is a body of best 284 practices based on long experience in this area. Numerous 285 techniques exist to help organizations balance protecting themselves 286 and providing services to their members, employees, and/or 287 customers. (Describing, or even enumerating, such techniques and 288 practices is beyond the scope of this document, but section 8 does 289 mention some.) 291 It is critical that protocol design and architecture permit such 292 practices, and not constrain them. One key way in which the design 293 of a new service can aid its secure deployment is to maintain the 294 one-to-one association of services and port numbers. 296 One or more firewalls might exist in the path between the client and 297 server systems, as well as between the Message Submission and IMAP 298 servers. Proper deployment REQUIRES that TCP connections be 299 possible from the client system to the IMAP and Message Submission 300 ports on the servers, as well as from the Message Submission server 301 to the IMAP server. This may require configuring firewalls to 302 permit such usage. 304 Firewalls deployed in the network path MUST NOT damage protocol 305 traffic. In particular, both message submission and IMAP 306 connections from the client MUST be permitted. Firewalls MUST NOT 307 partially block extensions to these protocols, such as by allowing 308 one side of an extension negotiation, as doing so results in the two 309 sides being out of synch, with later failures. See [FIREWALLS] for 310 more discussion. 312 Application proxies, which are a not uncommon mechanism, are 313 discussed in [PROXIES]. 315 6.1 Firewall Traversal 317 An often-heard complaint from those attempting to deploy new 318 services within an organization is that the group responsible for 319 maintaining the firewall is unable or unwilling to open the required 320 ports. The group which owns the firewall, being charged with 321 organizational network security, is often reluctant to open firewall 322 ports without an understanding of the benefits and the security 323 implications of the new service. 325 Gellens [Page 7] Expires November 2007 326 The group wishing to deploy a new service is often tempted to bypass 327 the procedure and internal politics necessary to open the firewall 328 ports. A tempting kludge is to tunnel the new service over an 329 existing service that is already permitted to pass through the 330 firewall, typically HTTP on port 80 or sometimes SMTP on port 25. 331 Some of the downsides to this are discussed in [KLUDGE]. 333 Such bypass can appear to be immediately successful, since the new 334 service seems to deploy. However, assuming the network security 335 group is competent, when they become aware of the kludge, their 336 response is generally to block the violation of organizational 337 security policy. It is difficult to design an application-level 338 proxy/firewall which can provide such access control without 339 violating the transparency requirements of firewalls, as described 340 in [FIREWALLS]. Collateral damage is common in these circumstances. 341 The new service (which initially appeared to have been successfully 342 deployed) as well as those existing services which were leveraged to 343 tunnel the new service, becomes subject to arbitrary and 344 unpredictable failures. This encourages an adversarial relationship 345 between the two groups, which hinders attempts at resolution. 347 Even more serious is what happens if a vulnerability is discovered 348 in the new service. Until the vulnerability is corrected, the 349 network security group must disable both the new service and the 350 (typically mission-critical) existing service on which it is 351 layered. 353 An often-repeated truism is that any computer which is connected to 354 a network is insecure. Security and usefulness are both 355 considerations, with organizations making choices about achieving 356 acceptable measures in both areas. Deploying new services typically 357 requires deciding to permit access to the ports used by the service, 358 with appropriate protections. While the delay necessary to review 359 the implications of a new service may be frustrating, in the long 360 run it is likely to be less expensive than a kludge. 362 7 NATs 364 Any NAT boxes which are deployed between client and server systems 365 MUST comply with REQ-5 in [BEHAVE-TCP], which requires that 'the 366 value of the "established connection idle-timeout" MUST NOT be less 367 than 2 hours 4 minutes.' 369 See section 5 for additional information on connection lifetimes. 371 Gellens [Page 8] Expires November 2007 372 Note that IMAP and message submission clients will automatically 373 re-open TCP connections as needed, but it saves time, packets, and 374 processing to avoid the need to do so. Re-opening IMAP and message 375 submission connections generally incurs costs for authentication, 376 TLS negotiation, and server processing, as well as resetting of TCP 377 behavior such as windows. It is also wasteful to force clients to 378 send NOOP commands just to maintain NAT state, especially since this 379 can defeat dormancy mode. 381 8 Security Considerations 383 There are numerous security considerations whenever an organization 384 chooses to make any of its services available via the Internet. 385 This includes email from mobile clients. 387 Sites concerned about email security should perform a threat 388 analysis, get relevant protections in place and then make a 389 conscious decision to open up this service. As discussed in section 390 6.1, piggybacking email traffic on the HTTP port in an attempt to 391 avoid making a firewall configuration change to explicitly permit 392 mobile email connections would bypass this important step and 393 reduces the overall security of the system. 395 Organizations deploying a messaging server "on the edge" (that is, 396 accessible from the open Internet) are encouraged to choose one that 397 has been designed to operate in that environment. 399 This document does not attempt to catalogue either the various risks 400 an organization might face or the numerous techniques which can be 401 used to protect against the risks. However, to help illustrate the 402 deployment considerations, a very small sample of some of the risks 403 and countermeasures appear below. 405 Some organizations are concerned that permitting direct access to 406 their mail servers via the Internet increases their vulnerability, 407 since a successful exploit against a mail server can potentially 408 expose all mail and authentication credentials stored on that 409 server, and can serve as an injection point for spam. In addition, 410 there are concerns over eavesdropping or modification of mail data 411 and authentication credentials. 413 A large number of approaches exist which can mitigate the risks 414 while allowing access to mail services via mobile clients. 416 Placing servers inside one or more DMZs (demilitarized zones, also 417 called perimeter networks) can protect the rest of the network from 418 a compromised server. An additional way to reduce the risk is to 419 store authentication credentials on a system which is not accessible 421 Gellens [Page 9] Expires November 2007 422 from the Internet, and which the servers within the DMZ can access 423 only by sending the credentials as received from the client and 424 receiving an authorized/not authorized response. Such isolation 425 reduces the ability of a compromised server to serve as a base for 426 attacking other network hosts. 428 Many additional techniques for further isolation exist, such as 429 having the DMZ IMAP server have no mail store of its own. When a 430 client connects to such a server, the DMZ IMAP server might contact 431 the authentication server and receive a ticket, which it passes to 432 the mail store in order to access the client's mail. In this way a 433 compromised IMAP server cannot be used to access the mail or 434 credentials for other users. 436 It is important to realize that simply throwing an extra box in 437 front of the mail servers, such as a gateway which may use HTTP or 438 any of a number of synchronization protocols to communicate with 439 clients, does not itself change the security aspects. By adding 440 such a gateway, the overall security of the system, and the 441 vulnerability of the mail servers, may remain unchanged or may be 442 significantly worsened. Isolation and indirection can be used to 443 protect against specific risks, but to be effective, such steps need 444 to be done after a threat analysis, and with understanding of the 445 issues involved. 447 Organizations SHOULD deploy servers which support the use of TLS for 448 all connections and which can be optionally configured to require 449 TLS. When TLS is used, it SHOULD be via the STARTTLS extensions 450 rather than the alternate port method. TLS can be an effective 451 measure to protect against specific threats, including eavesdropping 452 and alteration, of the traffic between the end-points. However, 453 just because TLS is deployed does not mean the system is "secure." 455 Attempts at bypassing current firewall policy when deploying new 456 services have serious risks, as discussed in section 6.1. 458 It's rare for a new service to not have associated security 459 considerations. Making email available to an organization's members 460 using mobile devices can offer significant benefits. 462 9 IANA Considerations 464 None. 466 Gellens [Page 10] Expires November 2007 467 10 Acknowledgments 469 Chris Newman and Phil Karn suggested very helpful text. Brian Ross 470 and Dave Cridland reviewed drafts and provided excellent 471 suggestions. 473 11 Normative References 475 [BEHAVE-TCP] "NAT Behavioral Requirements for TCP", 476 draft-ietf-behave-tcp-07.txt [in RFC Editor's Queue -- RFC Editor, 477 please replace with reference to RFC when published]. 479 [HOST-REQUIREMENTS] "Requirements for Internet Hosts -- 480 Communication Layers", R. Braden, RFC 1122, October 1989. 482 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement 483 Levels", S. Bradner, RFC 2119, BCP 14, March 1997. 485 [IANA] IANA Port Number Registry, 486 488 [TCP] "Transmission Control Protocol", J. Postel, RFC 793, STD 7, 489 September 1981. 491 12 Informative References 493 [ACAP] "ACAP -- Application Configuration Access Protocol", C. 494 Newman, J.G. Myers, RFC 2244, November 1997. 496 [FIREWALLS] "Behavior of and Requirements for Internet Firewalls", 497 N. Freed, RFC 2979, October 2000. 499 [IMAP] "Internet Message Access Protocol -- Version 4rev1", M. 500 Crispin, RFC 3501, March 2003. 502 [KLUDGE] "On the use of HTTP as a Substrate", K. Moore, BCP 56, 503 February 2002. 505 [PROFILE] "Lemonade Profile", S. Maes, A. Melnikov, RFC 4550, June 506 2006. 508 [PROXIES] "Classical versus Transparent IP Proxies", M. Chatel, RFC 509 1919, March 1996. 511 Gellens [Page 11] Expires November 2007 513 [SUBMISSION] "Message Submission for Mail", R. Gellens, J. Klensin, 514 RFC 4409, April 2006. 516 13 Author's Address 518 Randall Gellens 519 QUALCOMM Incorporated 520 5775 Morehouse Drive 521 San Diego, CA 92121 522 randy@qualcomm.com 524 Appendix A: Changes from Previous Version 526 THIS SECTION TO BE REMOVED PRIOR TO PUBLICATION. 528 Changes made from version -08 to -09 as a result of IESG DISCUSS by 529 Cullen Jennings: 530 o Added informative reference to draft-ietf-behave-tcp-07.txt in 531 third paragraph of Section 4. 532 o Replaced some text in Section 7 with a normative reference to 533 draft-ietf-behave-tcp-07.txt. 534 o Defined "idle" and "duration" at start of Section 4.1. 535 o Replaced text in Section 4.2 on TCP soft errors with reference 536 to RFC 1122. 537 o Replaced repetition of requirements in Section 5 with references 538 to Sections 4.1 and 4.2. 539 o Deleted first paragraph in Section 7. 540 o Reworded third paragraph in Section 8 to eliminate the word 541 "indemnity". 542 o Reworded text in Section 3 regarding configuration data. 543 o Reworded text on the TCP keep-alive option in Section 4.2. 544 o Deleted word "ridiculously" in Section 7. 545 o Added clarification at end of last paragraph of Section 5. 546 o Added normative reference [BEHAVE-TCP]. 548 Changes made from version -07 to -08 as a result of IESG DISCUSS by 549 Cullen Jennings: 550 o Added text to section 4.1 explaining that the two-hour maximum 551 idle time is the default, while still permitting specific 552 configurations to exceed this to maximize dormancy. 553 o Changed ICMP soft errors from SHOULD NOT to MUST NOT. 555 Changes made from version -06 to -07 as a result of IESG DISCUSS by 556 Cullen Jennings: 557 o Removed prohibition on NATs closing connections just because of 558 how long they have been open, without taking any other factor 560 Gellens [Page 12] Expires November 2007 561 into account. Replaced with discussion on the issue and 562 recommendation that lemonade clients not allow connections to 563 remain idle for two hours, unless they have specific 564 configuration instructions to do so (e.g., in networks where 565 NATs and firewalls allow this, and the IMAP server permits it) 566 o Changed explicit note to permit all systems to terminate TCP 567 connections at any time based on local decisions 568 o Removed word "insurance" 570 Changes made from version -05 to -06 as a result of IESG DISCUSSes 571 by Jari Arkko, Lars Eggert, Cullen Jennings, and Magnus Westerlund: 572 o Clarified that "support" for TCP means availability of TCP to 573 applications, as opposed to deployment or use of TCP within a 574 network 575 o Clarified that an HTTP-only environment can offer webmail, which 576 may be email, but isn't lemonade email 577 o Added explicit note that end systems remain able to terminate 578 TCP connections at any time based on local decisions 579 o Made [FIREWALLS] an informative, not normative reference by 580 restating requirement 581 o Additional clarifications to make draft easier to read from a 582 non-Applications Area viewpoint 584 Changes made from version -04 to -05 as a result of IETF Last Call: 585 o Fixed some typos. 586 o Made first use of TCP into a reference. 588 Changes made from version -03 to -04 as a result of WG Last Call: 589 o New boilerplate text 590 o Wording tweaks from lemonade list (e.g., expanding contractions) 591 o Explcitly state that support for TCP is REQUIRED 592 o Correct reference in timeout text from PROFILE to IMAP 593 o Add RFC number to KEYWORDS reference (nit checker doesn't like 594 BCP number only) 595 o Move HOST-REQUIREMENTS reference to normative from informative 596 o Add TCP reference (since TCP support is REQUIRED) 597 o Add IMAP reference (for port number) 598 o Update PROFILE reference to RFC (from RFC Ed pub queue) 600 Intellectual Property Statement 602 The IETF takes no position regarding the validity or scope of any 603 Intellectual Property Rights or other rights that might be claimed 604 to pertain to the implementation or use of the technology described 605 in this document or the extent to which any license under such 606 rights might or might not be available; nor does it represent that 607 it has made any independent effort to identify any such rights. 608 Information on the procedures with respect to rights in RFC 610 Gellens [Page 13] Expires November 2007 611 documents can be found in BCP 78 and BCP 79. 613 Copies of IPR disclosures made to the IETF Secretariat and any 614 assurances of licenses to be made available, or the result of an 615 attempt made to obtain a general license or permission for the use 616 of such proprietary rights by implementers or users of this 617 specification can be obtained from the IETF on-line IPR repository 618 at http://www.ietf.org/ipr. 620 The IETF invites any interested party to bring to its attention any 621 copyrights, patents or patent applications, or other proprietary 622 rights that may cover technology that may be required to implement 623 this standard. Please address the information to the IETF at 624 ietf-ipr@ietf.org. 626 Full Copyright Statement 628 Copyright (C) The IETF Trust (2007). 630 This document is subject to the rights, licenses and restrictions 631 contained in BCP 78, and except as set forth therein, the authors 632 retain all their rights. 634 This document and the information contained herein are provided on 635 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 636 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 637 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 638 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 639 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 640 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 641 FOR A PARTICULAR PURPOSE. 643 Gellens [Page 14] Expires November 2007