<Lemonade in TCP Challenged Environments> June 2006 Lemonade S. H. Maes Internet Draft: Lemonade TCP Challenged R. Cromwell Environments (Editors) Document: draft-maes-lemonade-tcp-challenged- environments-01 Expires: December 2006 June 2006 Lemonade in TCP Challenged Environments Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 30, 2006. Abstract The IETF lemonade group has defined extensions to the IMAP and SMTP protocols that provide optimizations for clients in a variety of settings, such as mobile networks. This document discusses issues related to deployments where TCP support in the client is degraded or non-existent, and techniques for overcoming these limitations. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. Maes Expires December 2006 [Page 1]
<Lemonade in TCP Challenged Environments> June 2006 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 [RFC2119]. An implementation is not compliant if it fails to satisfy one or more of the MUST or REQUIRED level requirements for the protocol(s) it implements. An implementation that satisfies all the MUST or REQUIRED level and all the SHOULD level requirements for a protocol is said to be "unconditionally compliant" to that protocol; one that satisfies all the MUST level requirements but not all the SHOULD level requirements is said to be "conditionally compliant." When describing the general syntax, some definitions are omitted as they are defined in [RFC3501], [RFC821], and related documents. Table of Contents Status of this Memo...............................................1 Abstract..........................................................1 Conventions used in this document.................................1 Table of Contents.................................................2 1. Introduction and motivation....................................2 2. Techniques.....................................................3 2.1. Tunneling Approaches......................................3 2.1.1. Non-Persistent HTTP for Batch Connectivity Mode......5 2.1.2. Using Persistent HTTP/HTTPS + Chunked Transfer Encoding for Stream Connectivity Mode................7 2.1.3. Using HTTP as a binding for SMTP.....................8 3. Asynchronous Approaches........................................8 3.1. Transmission Methods......................................9 3.2. Authentication............................................9 3.3. Response Payload..........................................9 4. Tracking and Controlling Tunneled Traffic......................9 5. Security Considerations.......................................10 References.......................................................10 Future Work......................................................11 Version History..................................................11 Acknowledgments..................................................12 Authors Addresses................................................12 Intellectual Property Statement..................................12 Disclaimer of Validity...........................................13 Copyright Statement..............................................13 1. Introduction and motivation The IETF lemonade working group is designing a set of extensions to IMAP and SMTP to facilitate access to internet email in diverse service environments, such as on resource constrained devices, and Maes Expires December 2006 [Page 2]
<Lemonade in TCP Challenged Environments> June 2006 slow or high latency networks. The preferred model and best current practices for doing this is described in [DEPLOYMENTS]. Not all networks and clients permit the preferred deployment model at this point in time, such as some devices which do not provide a TCP stack to the application (some mobile phones and set-top box environments), and some networks with very high and unpredictable latency like satellite networks. Over time, it is expected that as technology improves, some of these limitations will be lifted to permit deployment using best current practices. However, it is desirable to provide some form of access for users of these networks until that time. 2. Techniques Examples of major markets that have some TCP limitations include: - Some Java MIDP devices do not permit arbitrary TCP, but do permit HTTP - TV Set-top box providers which may provide degraded TCP or HTTP over MPEG-2 - Global satellite wireless networks which provide email in remote environments and at sea. This document considers two techniques to overcome these difficulties. The first is HTTP Tunneling to attempt regular IMAP and SMTP layered on top of HTTP. The second technique is a URL mapping approach which uses [IMAPURL] as a compact representation for sending batches of IMAP commands over severely limited physical networks like two-way satellite networks. Servers and clients adhering to this draft MUST support HTTP tunneling, and MAY support section 3's IMAPURL approach. 2.1. Tunneling Approaches There are two approaches for achieving tunneling over HTTP, depending on whether keep-alive chunked-transfer-encoded is supported by any intermediaries in the network (i.e. HTTP proxy servers) or not. The general approach is to use a content-type for packaging a payload of IMAP commands, described below. To use HTTP/HTTPS as the transfer protocol for IMAP commands and responses between the IMAP client and server, the client MUST send an HTTP POST request to the server, and embed IMAP commands (commands to an IMAPv4 Rev1 server or IMAP servers supporting Lemonade extensions) in the body of the request. A server MUST reject a HTTP GET request from the client. The content-type header of the POST request MUST be set to "application/vnd.lemonade.imap". Multiple IMAP commands may Maes Expires December 2006 [Page 3]
<Lemonade in TCP Challenged Environments> June 2006 be included in one POST request. In general, the HTTP server is expected to preserve session state between HTTP commands to the best of its ability, therefore the client does not need to reauthenticate and reissue a SELECT until it receives an (IMAP) error response showing that it is not authenticated. In what follows, the term Lemonade client/server is used to refer to a client/server that supports both IMAPv4 Rev1 as well as any LEMONADE extensions. When the HTTP binding is used, the Lemonade server listens on whatever port has been configured for this. The following is an example of a Lemonade HTTP request: POST /lemonadePath HTTP/1.1 <CRLF> Content-Type: application/vnd.lemonade.imap <CRLF> X-Http-Binding: imap <CRLF> [other headers] <CRLF> (<tag> SP <Lemonade command> <CRLF> | literal ) [(<tag> SP <Lemonade command> <CRLF> | literal )] The Lemonade command MUST be plain text (7bit). Multiple Lemonade commands MAY be sent on the same request. The client must be able to deal with recovering from errors when commands are batched. See RFC2442 Batch SMTP for a further discussion. In general, if a command is expected to produce a synchronized literal or continuation request, it MUST be the last command in the batch. The Content-Type and X-Http-Binding headers are the only HTTP headers that MUST be sent to a Lemonade server. Other headers such as Cache- Control MAY be included. When the Lemonade server sends back a response it is in following format: HTTP/1.1 <HTTP Status Code> <CRLF> Content-Type: application/vnd.lemonade.imap <CRLF> X-Http-Binding: imap <CRLF> <CRLF> [<untagged responses>] <tag> SP <Lemonade Server response> <CRLF> [<untagged responses>] <tag> SP <Lemonade Server response> <CRLF> The Lemonade Server uses the following HTTP status codes, and what each code indicates is given below: Maes Expires December 2006 [Page 4]
<Lemonade in TCP Challenged Environments> June 2006 - 200 -This indicates normal execution of the Lemonade commands from an IMAP perspective. The client should further parse the response body to get the tagged responses to the commands and process those accordingly. - 401 - This indicates that the execution of the IMAP commands might have been successful, but the session is no longer authenticated. The client should try to reauthenticate to the IMAP server, and then resend the commands. - 5xx - This indicates that at least one command was malformed/protocol level error, or, a command could not complete due to a problem in the IMAP server. In conforming to HTTP semantics, this means the IMAP server responses such as BAD or NO on a tagged response generate a HTTP 500 response code. Also, if the HTTP request includes batched commands after the command which generates a continuation request or synchronized literal, the server MUST generate a 5xx request. When using HTTP to transfer IMAP commands and responses, the client SHOULD utilize built-in features of HTTP to their advantage. For example, the client SHOULD use HTTPS instead of HTTP whenever possible, since HTTPS has built in encryption and MAY have compression capabilities. HTTP can be used in both batch and stream modes. Details about these transport modes are given in the following two subsections. 2.1.1. Non-Persistent HTTP for Batch Connectivity Mode If the client uses a traditional HTTP connection (either by establishing a different socket for each HTTP request to the Lemonade server, or by reusing the same socket for all HTTP requests, but sending each request in different HTTP commands), it has batch connectivity to the server. The client can issue as many commands as it would like in one HTTP request to the server, and the server responds by sending back one HTTP response with all the responses to all the commands in the HTTP request. With this connectivity mode, the IDLE command nor any commands that depend on unsolicited responses in a session. Other commands that use a continuation response or synchronized literal cannot be issued unless they are the last command in the batch. [LITERAL+] SHOULD be used to eliminate synchronized literals when using APPEND. Maes Expires December 2006 [Page 5]
<Lemonade in TCP Challenged Environments> June 2006 In order for the server to identify separate HTTP requests as belonging to the same session, a batch HTTP client needs to accept cookies. A session-id is passed in the cookie to identify the session. Example: the headers for a HTTP batch response after the client has issued its first HTTP request to the server. HTTP/1.1 <HTTP Status Code> <CRLF> Content-Type: application/vnd.lemonade.imap <CRLF> X-Http-Binding: imap <CRLF> Set-Cookie:JSESSIONID=94571a8530d91e1913bfydafa; path=/lemonade<CRLF> <CRLF> [<untagged responses>] <tag> SP <Lemnade Server response> <CRLF> [[<untagged responses>] <tag> SP <Lemonade Server response> <CRLF>] Example: the headers for a HTTP batch response after the client has issued its first HTTP request to the server, with the final command generating a continuation request. HTTP/1.1 200 Ok <CRLF> Content-Type: application/vnd.lemonade.imap <CRLF> X-Http-Binding: imap <CRLF> Set-Cookie:JSESSIONID=94571a8530d91e1913bfydafa; path=/lemonade<CRLF> <CRLF> [<untagged responses>] <tag> SP <Lemnade Server response> <CRLF> +continuation-request The client must then save this cookie and send it back to the server with the next request in order for the server to reattach these commands to the same session as the previous commands. POST /lemonadePath HTTP/1.1 <CRLF> Content-Type: application/vnd.lemonade.imap <CRLF> X-Http-Binding: imap <CRLF> Cookie: JSESSIONID=94571a8530d91e1913bfydafa [other headers] <CRLF> <tag> SP <Lemonade command> <CRLF> [<tag> SP <Lemonade command> <CRLF>] Maes Expires December 2006 [Page 6]
<Lemonade in TCP Challenged Environments> June 2006 2.1.2. Using Persistent HTTP/HTTPS + Chunked Transfer Encoding for Stream Connectivity Mode It is possible to use persistent HTTP or persistent HTTPS plus chunked-transfer-encoding so that the client and server can use stream style communications. The client needs to open a persistent HTTP connection and keep it active. In this case, the HTTP headers must be sent the first time the client device opens the connection to the Lemonade Server and these headers MUST set the transfer coding to be chunk-encoded [RFC2616, Sec. 3.6.1]. All subsequent client-server requests are written to the open connection, without needing any additional HTTP headers. In this case, the client does not need to accept cookies. The client must send the HTTP headers one time only: POST /lemonadeServletPath HTTP/1.1 <CRLF> Content-Type: application/vnd.lemonade.imap <CRLF> Connection: keep-alive <CRLF> X-Http-Binding: imap <CRLF> Pragma: no-cache <CRLF> Transfer-Encoding: chunked <CRLF> The server responds with the following header: HTTP/1.1 <HTTP Status Code> <CRLF> Cache-Control: private Keep-Alive: timeout=15, max=100 (or other suitable setting) Connection: Keep-Alive X-Http-Binding: imap <CRLF> Transfer-Encoding: chunked Content-Type: application/vnd.lemonade.imap Then the client can send a command anytime it wants with the following format: <length of Lemonade command, including bytes in CRLF> <CRLF> <tag> SP <Lemonade command> <CRLF> <CRLF> And example of an actual client command is: e <CRLF> 2 CAPABILITY<CRLF> <CRLF> The server responds to each command with as many untagged responses as needed, and one tagged response, where each response is in the format that follows: Maes Expires December 2006 [Page 7]
<Lemonade in TCP Challenged Environments> June 2006 <length of a single response, including bytes in CRLF> <CRLF> <tagged or untagged response> <CRLF> <CRLF> An actual Server response might be: d5 <CRLF> * CAPABILITY IMAP4REV1 AUTH=LOGIN NAMESPACE SORT MULTIAPPEND LITERAL+ UIDPLUS IDLE XORACLE X-ORACLE-LIST X-ORACLE-COMMENT X- ORACLE-QUOTA X-ORACLE-PREF X-ORACLE-MOVE X-ORACLE-DELETE ACL X- ORACLE-PASSWORD LDELIVER LZIP LCONVERT LFILTER LSETPREF LGETPREF <CRLF> <CRLF> 1b <CRLF> 2 OK CAPABILITY completed <CRLF> <CRLF> Note however that the HTTP protocol is in general not meant to be used in such a way. To maintain such an open channel might be a practical challenge to proxies, which might not forward the requests chunk by chunk to the server, and meanwhile route responses back to the client chunk by chunk. Consequently the session closes. Chunked transfer encoding requests MAY not be honored by an HTTP proxy server. In cases where such requests are denied, the client should be prepared to use the non-chunked encoding technique from section 2.1.1. The session may be automatically started again by the client after a lost connection or by the server through out-of-band; after some defined time-out. 2.1.3. Using HTTP as a binding for SMTP All of the techniques described in sections 2.1 may be used for SMTP as well. The only difference between IMAP and SMTP will be the HTTP URL used. Servers implementing the HTTP binding are expected to differentiate between IMAP and SMTP protocol bodies via the URL. 3. Asynchronous Approaches Some networks, such as satellite networks, may present challenges to the HTTP request-response approach in the preceding chapter due to extreme latency. Clients expecting near-synchronous response to IMAP commands would face huge delays, and may inappropriately timeout too soon, or provide a UI to the user that is geared around immediate response which will expose long delays to end users. Satellite networks resemble store-and-forward systems, it is thus desirable to provide a mechanism for interacting with an IMAP Maes Expires December 2006 [Page 8]
<Lemonade in TCP Challenged Environments> June 2006 Lemonade server that is geared for asynchronous requests and responses. [IMAPURL] already provides a standard for encoding a series of IMAP commands into a compact URL, and describes a subset of functionality that is adequately suited to accessing email when roaming on satellite networks. 3.1. Transmission Methods It is not in the scope of this document to describe the mechanism by which IMAPURL payloads are sent through such networks (which are typically proprietary) However, the end result should be an HTTP request invoked on a server which decodes the IMAPURL payload and processes the request on behalf of the client. IMAPURLs of the form imap://<iserver>/path?query where iserver = [iuserinfo "@"] host [":" port] must be rewritten into a URL of the following form: http://host:port/lemonade?imapurl=<enc-imapurl> where <enc-imapurl> is imap://<iserver>/path?query encoded according to standard HTTP url encoding. 3.2. Authentication <<Ray: TBD, Perhaps the Delay Tolerant Networking working group has some material on authenticating over DTNs? Or perhaps a mechanism for obtaining longer lived URLAUTH tokens which can be reused multiple URLs within a time span?>> 3.3. Response Payload The response to any IMAPURL processed according to [IMAPURL] on the server should be sent to the client as a set of raw IMAP responses. However, [IMAPURL] suggests that the result of a search should be to fetch all the messages returned from the SEARCH. For the purposes of this document, the result of an IMAPURL containing a search should be the SEARCH response from the IMAP server, without performing any FETCHes. 4. Tracking and Controlling Tunneled Traffic In order to simplify deployment and provisioning issues, as well as help network administrators track and control IMAP/SMTP traffic wrapped in HTTP requests, the HTTP requests and responses of a Maes Expires December 2006 [Page 9]
<Lemonade in TCP Challenged Environments> June 2006 binding should provide a non-ambiguous way of recognizing binding traffic. It is therefore mandated that a "X-HTTP-Binding" HTTP header MUST specified in all requests and responses. The header may take a value of "imap" or "smtp" depending on the type of traffic being tunneled. 5. Security Considerations The HTTPS protocol can and should be used to provide end-to-end security where it is available when tunneling, especially because of the existence of HTTP proxies. Caching is also a concern, especially if HTTPS isn't used. The client SHOULD use the HTTP Cache-Control directive (no-cache, no-store, must-revalidate, or combinations thereof) to inform proxy servers, origin servers, and client libraries not to cache or store the HTTP response. To deal with HTTP 1.0 servers that may exist in the network, Pragma: no-cache should be used as well. Attacks on HTTP sessions and the HTTP server may also be a concern, since the HTTP server is maintaining an authenticated session to the IMAP server on behalf of the user in most cases. Network administrators wishing to block stealth deployments of HTTP IMAP bindings may block HTTP requests with Content-Type application/vnd.lemonade.[imap|smtp] via an application level firewall and/or block any HTTP traffic with the X-Http-Binding header defined. References [DEPLOYMENTS] Gellens, R., " Deployment Considerations for lemonade- compliant Mobile Email", draft-ietf-lemonade-deployments-03.txt, June 2006. [LEMONADEPROFILE] Maes, S.H. and Melnikov A., "Lemonade Profile", draft-ietf-lemonade-profile-XX.txt, (work in progress). [LUOTONEN] Luotonen, A., Tunneling TCP based protocols through Web proxy servers, draft-luotonen-web-proxy-tunneling-01.txt, August 1998 [LITERAL+] Myers, J. IMAP non-synchronizing literals, RFC2088, January 1997 http://www.ietf.org/rfc/rfc2088 Maes Expires December 2006 [Page 10]
<Lemonade in TCP Challenged Environments> June 2006 [P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and Chiu, E., Day, J., Ahad R., Jeong W-H., Rosell G., Sini, J., Sohn S- M., Xiaohui F. and Lijun Z., "Push Extensions to the IMAP Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in progress). [RFC2119] Brader, S. "Keywords for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119 [RFC2442] Freed, N. et al. "The Batch SMTP Media Type", RFC 2442, November 1998. http://www.ietf.org/rfc/rfc2442 [RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. http://www.ietf.org/rfc/rfc2616 [RFC2817] Khare, R., Upgrading to TLS Within HTTP/1.1, RFC2817, May 2000 http://www.ietf.org/rfc/rfc2817.txt, May 2000 [RFC3205] Moore, K. On the use of HTTP as a Substrate, RFC 3205, February 2002. http://www.ietf.org/rfc/rfc3205 [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol Version 4 rev1", RFC 3501, March 2003. http://www.ietf.org/rfc/rfc3501 Future Work - Detail normative statements on binding method to support versus other options that were considered. Version History Release 01 Change name and focus to TCP challenged environment Emphasize usage in challenged network and platform environments Added more examples of challenged environments Discussion of IMAPURL for satellite networks, New X-HTTP-Binding header Normative statements Release 00 Rename from firewall binding. Maes Expires December 2006 [Page 11]
<Lemonade in TCP Challenged Environments> June 2006 Acknowledgments The authors want to thank all who have contributed key insight and extensively reviewed and discussed the concepts in this draft as well as the authors of the early introduction of the binding concept in [P-IMAP]. Authors Addresses Stephane H. Maes Oracle Corporation 500 Oracle Parkway M/S 4op634 Redwood Shores, CA 94065 USA Phone: +1-650-607-6296 Email: stephane.maes@oracle.com Ray Cromwell Oracle Corporation 500 Oracle Parkway Redwood Shores, CA 94065 USA Nilo Mitra Ericsson Tel: +1 212-843-8451 Email: nilo.mitra@ericsson.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. Maes Expires December 2006 [Page 12]
<Lemonade in TCP Challenged Environments> June 2006 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Maes Expires December 2006 [Page 13]