Internet DRAFT - draft-maes-lemonade-tcp-challenged-environments
draft-maes-lemonade-tcp-challenged-environments
<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]
