Internet DRAFT - draft-smaes-lemonade-intermediary-challenges
draft-smaes-lemonade-intermediary-challenges
<Lemonade and Intermediary Challenges> October 2005
Lemonade
Internet Draft: Challenges of Intermediaries S. H. Maes
Document: draft-smaes-lemonade-intermediary-
challenges-02.txt
Expires: April 2006 October 2005
Lemonade and the challenges of Intermediaries
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.
Abstract
This document discusses some of the issues posed by firewalls and
other intermediaries to deployment of some basic IETF technologies.
The intent of this document is to track such issues, explore possible
approaches elegant or not that have been proposed so far to address
them and initiate discussion on how such issues should be
appropriately addressed by IETF.
This first version 00 is provided to initiate discussion. Most of the
content should be considered as initial place holders.
Conventions used in this document
Maes Expires - April 2006 [Page 1]
<Lemonade and Intermediary Challenges> October 2005
In examples, "C:" and "S:" indicate lines sent by the client server
respectively.
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].
Table of Contents
Status of this Memo ........................................... 1
Abstract....................................................... 1
Conventions used in this document.............................. 1
Table of Contents.............................................. 2
1. Introduction................................................ 2
2. Description of the problem.................................. 3
2.1. Mobile e-mail with IMAP4, POP3 and SMTP................ 3
2.2. Lemonade............................................... 4
2.3. Some challenges met with P-IMAP........................ 5
2.3.1. HTTP / HTTPS firewalls............................ 5
2.3.2. Time-outs......................................... 5
2.3.3. Deployment challenges............................. 5
3. Analysis.................................................... 5
4. Initial considerations: A wish list for Lemonade............ 6
5. HTTP Binding................................................ 6
Security Considerations........................................ 7
References..................................................... 8
Future Work.................................................... 8
Version History................................................ 8
Acknowledgments................................................ 9
Authors Addresses.............................................. 9
Intellectual Property Statement................................ 9
Full Copyright Statement.......................................10
1.
Introduction
Lemonade provides enhancements to Internet email to support diverse
service environments.
As discussions started to understand broader challenges of e-mail,
the case of mobile e-mail was discussed. This discussion found at
[MEMAIL] and [OMA-ME -AD].
In these documents, it was pointed out that numbers of (mobile) email
deployment based on existing IETF specifications are not usable or
encounter difficulties because the protocols often can not traverse
firewalls with constrained settings (e.g. only allow HTTP or HTTPS).
Maes Expires - April 2006 [Page 2]
<Lemonade and Intermediary Challenges> October 2005
Unavailability of submit port (e.g. SMTP) are other problems.
In addition, many intermediaries found in mobile deployments between
clients and servers are often set with limited timeout for pinholes,
sessions etc...
In particular, in the context of mobile network, it has been observed
that IDLE sessions on TCP are much less stable than IDLE sessions
over HTTP Binding.
2.
Description of the problem
2.1.
Mobile e-mail with IMAP4, POP3 and SMTP
Following the analysis presented in [MEMAIL], [OMA-ME-RD] and [OMA-
ME-AD], a typical context for mobile users trying to access their e-
mail is the following:
- The user is on a mobile network, using a mobile device
- The mobile device presents limitations in terms of the type of
software / client that it can run
- The device has limited resource capabilities and in particular is
constrained by consideration on its battery life
- The network provided by one or multiple service providers
(operator) may present additional constraints, unreliability or other
typical mobile behavior.
- In general traffic is expensive.
- The e-mail server is located in a corporation, behind a firewall.
- The corporation has issued strict security and usage guidelines.
- Multiple intermediaries and firewalls may exist between the mobile
server and the corporate domain.
Accordingly, users are often reduced to using the available e-mail
clients on the mobile device (e.g. POP3 or IMAP4 and SMTP).
For the sake of argument, let us assume that he or she uses a
IMAP4/SMTP e-mail client.
In order to receive and send e-mail, while satisfying its corporate
guidelines, the user must be able to connect via IMAP4 and SMTP to
its corporate server. We have observed the following challenges:
- Some corporations guidelines prevent open in the firewall the ports
used by IMAP 4 or SMTP, therefore preventing the user to access his
or her e-mail just using this code.
- Some corporations rightfully forbid using these protocols outside
of secure connections (e.g. TLS, VPN).
More and more often, mobile device support TLS [RFC2246], not
necessarily the latest version. We have observed the following
challenges:
Maes Expires - April 2006 [Page 3]
<Lemonade and Intermediary Challenges> October 2005
- Some corporation guidelines prevent open in the firewall the ports
used by IMAP 4 over TLS or SMTP over TLS, therefore preventing the
user to access his or her e-mail.
As a result only user equipped with VPN clients compatible with their
corporate VPN will be able to access their e-mail. Unfortunately, VPN
clients on mobile devices are still rare. Installation on mobile
device is difficult if not often impossible. As a result employees of
corporation that use customized VPN clients are totally unable to use
their IMAP4 / SMTP client to access e-mail.
Note also that even when using VPN, drops of connectivity, time outs
of the intermediaries etc ... often disconnect the VPN. This is
expensive and inefficient, especially if this forces applications
like e-mail to re-send the same data multiple times. As corporation
guidelines also prevent VPN automatic reconnect and password saving
on the mobile device, users are rapidly very frustrated.
The only user friendly and viable solutions to access corporate e-
mail that remain are typically based on proprietary solutions
available only on particular devices and network and compatible only
with certain e-mail servers. These are typically costly, not widely
available to most users. They establish their own secure reliable
channel with push capability between the client and the device,
sometimes involving network specific intermediaries (E.g. NOC –
Network Operating Center). Proposals like Push IMAP [P-IMAP] attempt
to address this with a more open standard oriented approach.
In addition, IMAP IDLE over TCP (TLS) turns out to be very instable
over mobile networks (2.5G / GPRS as well as 3G); much more than IDLE
over HTTP [HTTPBinding]. It is conjectured that this results from the
properties and settings of the gateways and equipment in the
operators core network infrastructure that have HTTP / HTTPS port
time out different that other ports... It is unclear if this is
easily addressable by changing settings or configurations.
2.2.
Lemonade
Time outs of intermediaries are one of the fact or that contribute to
the frequent losses of connectivity of mobile devices.
In order to more efficiently address these issues with e-mail, and
assuming that the firewall issue is not an issue, Lemonade introduced
it its profile [LEMONADEPROFILE] a quick reconnect scheme
[RECONNECT].
Maes Expires - April 2006 [Page 4]
<Lemonade and Intermediary Challenges> October 2005
2.3.
Some challenges met with P-IMAP
2.3.1. HTTP / HTTPS firewalls
Among the solutions to address the firewall issues, Push_IMAP [P-
IMAP], describes and allows binding to HTTP [RFC2616] as a possible
option.
P-IMAP proposes also mechanisms to handle losses of connections.
However time-out and intermediaries still lead to challenges.
2.3.2. Time-outs
For example, use of HTTP long live session / chunk encoding
([RFC2616]) described in [P-IMAP], [HTTPBinding] to support exchange
of asynchronous events from the server to the client; while
technically sound, in practice does not work very well if
intermediaries time-out too rapidly; hence the good performances over
mobile network. It is very difficult to assess such time out in
general.
2.3.3. Deployment challenges
In general intermediaries also introduce additional security threats,
especially if they perform protocol transformations while located
across domains of trust. When such intermediaries are used across
domains, it is possible that additional application level
confidentiality, integrity and signature mechanisms must be
introduced. In P-IMAP for example, emails and notification may be
encrypted at the e-mail application level. Of course using SMIME
[RFC2633] is another viable approach.
<< Editor’s note: Add any additional discussions, examples...>>
3.
Analysis
Based on the examples discussed above, it seems clear that while
there may not be any conceptual or design problem with the core
protocol involved, there are issues with using them in real life
deployments.
In particular, it seems that we need to better understand:
- How to deal with the issues posed by intermediaries?
- How to appropriately separate the role of lower layers versus
application level to provide transport and security when
intermediaries are involved and such problems are met.
At this stage, this may involve the design of IETF protocols,
guidelines for implementation and deployment of these protocols and
Maes Expires - April 2006 [Page 5]
<Lemonade and Intermediary Challenges> October 2005
guidelines for implementation and deployments of intermediaries and
in particular firewalls.
Note also that the Lemonade discussions on traffic compression for
(mobile e-mail) may also warrant compression in such discussions.
4.
Initial considerations: A wish list for Lemonade
<< Editor’s note: This section is expected to contain a discussion of
what lemonade would like to see addressed. As a first stab this may
include the following.>>
We propose to collect feedback and to study feasibility and
appropriateness of defining:
- Ways to deal at the transport level with firewalls with constrained
settings.
- Ways to deal at the transport level with implementation or
deployment based time-outs; even if no such time outs are built in
the underlying protocols.
- Ways or guidelines to perform some of these functions at the
application level, when there are no transport level viable approach
and when it is judged that this does not warrant changes at the
transport level or below.
- Guidelines for implementation and deployment of intermediaries to
mitigate the issues identified in this document.
- Ways and guidelines to deal with the instabilities and time out
observed over mobile networks.
5.
HTTP Binding
As part of the LEMONADE goal to define extensions to the IMAPv4 Rev1
protocol [RFC3501] for providing optimizations in a variety of
settings, this document describes how HTTP can optionally be used to
transfer IMAP commands and responses. This binding is intended to
facilitate the use of IMAP in deployments involving a variety of
intermediaries, and offers a standardized alternative to de facto
proprietary implementations of such a feature.
The need for an optional HTTP binding is driven by the needs of the
mobile network operator community (see [MEMAIL],[OMA-ME-RD]), where
the reuse of an existing and well-understood technology will allow
operators to apply their experience in solving practical deployment
issues. Specifically, HTTP allow operators to reuse a similar setup
and model that is already used for many other similar and related
services, such as certain proprietary push e-mail and synchronization
offerings, OMA Data Synchronization, Web services and Web access.
Maes Expires - April 2006 [Page 6]
<Lemonade and Intermediary Challenges> October 2005
Using HTTP/HTTPS can simplify deployment in a corporate network
through the potential use of a reverse proxy to achieve end-to-end
encryption. This also has the advantage of not requiring changes to
any firewall configurations and reduces the concerns that this often
presents to corporation. In general the solution is compatible with
any existing firewall. A reverse proxy can also support deployment
models that offer roles to other service providers in the value
chains, as discussed in [OMA-ME-AD].
The security, encryption and compression capabilities used with HTTP
and already implemented in a wide range of existing mobile device,
which be also be reused.
Studies have also shown that a persistent HTTP session has usually
proven more resilient than an IMAP IDLE over TCP connection over an
unreliable bearer such as a GPRS-based mobile network.
The use of HTTP as an underlying protocol for other application
protocols has received much attention (see [RFC3205]). In particular,
the concern exists that this circumvents firewall security policies.
Another concern is the potential misuse or neglect of HTTP semantics
by the application protocol that uses HTTP as a substrate.
Note that if the suppression of IMAP (or indeed any other
application) traffic on HTTP/HTTPS is an issue, firewall
administrators can still prevent such passage and this can provide
incentives to re-configure firewalls to allow solutions on other
transports (e.g. TLS) or offer the HTTP-based solution using another
provisioned port (e.g. manually, out of band or via instructions like
XGETLPREFS (see [NOTIFICATIONS])). The aim, therefore, is to allow
for the use of this solution in the widest possible set of
circumstances by codifying a standard way to do so that works with
existing, deployed (i.e., HTTP only) firewalls, while explicitly
allowing the possibility of detecting and filtering such traffic in
deployments using the HTTP Content-Type in deployments where this is
not permitted.
Alternative HTTP bindings can be considered:
- SOAP binding
- REST binding
- WebDAV binding
Security Considerations
Security considerations are discussed throughout section 2 with
respect to firewalls, confidentiality, integrity and the risk posed
by intermediaries.
Maes Expires - April 2006 [Page 7]
<Lemonade and Intermediary Challenges> October 2005
Additional issues relate to how firewall issues are resolved.
<< Editor’s note: More to be added as document expands.>>
References
[HTTPBINDING] Maes, S.H., "Lemonade HTTP Binding", draft-maes-
lemonade-http-binding-02.txt, (work in progress).
[LEMONADEPROFILE] Maes, S.H. and Melnikov, A., "Lemonade Profile",
draft-ietf-lemonade-profile-xx.txt, (work in progress)
[MEMAIL] Maes, S.H., “Lemonade and Mobile e-mail", draft-maes-
lemonade-mobile-email-xx.txt, (work in progress).
[OMA-ME-AD] Open Mobile Alliance Mobile Email Architecture Document,
(Work in progress). http://www.openmobilealliance.org/
[OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document,
(Work in progress). http://www.openmobilealliance.org/
[P-IMAP] Maes, S.H., Lima R., Kuang, C., Cromwell, R., Ha, V. and
Chiu, E., Day, J. and Sini, J., "Push Extensions to the IMAP
Protocol (P-IMAP)", draft-maes-lemonade-p-imap-xx.txt, (work in
progress).
[RECONNECT] Melnikov, A. and C. Wilson, "IMAP4 extension for quick
reconnect", draft-ietf-lemonade-reconnect-XX.txt, work in
progress).
[RFC2246] Dierks, T. et al., "The TLS Protocol", version 1.0 RFC2246,
January 1999. ftp://ftp.ietf.org/rfc/rfc2246.txt
[RFC2616] Fielding, R. et al. "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. http://www.ietf.org/rfc/rfc2616
[RFC2633] Ramsdell, B. et al., "S/MIME Version 3 Message
Specification", RFC2633, June 1999.
http://www.ietf.org/rfc/rfc2633.txt.
Future Work
- Complete analysis of issues over mobile network (time-out)
- Complete analysis of all options for HTTP bindings
- Address all editor’s notes
Version History
Maes Expires - April 2006 [Page 8]
<Lemonade and Intermediary Challenges> October 2005
Revision 02:
[1] Editorial fixes.
[2] Details on IDLE instabilities in introduction and sections 2,
2.3.2 and 4.
[3] New references in section 2.1
[4] New HTTP binding section
[5] Updates in Security section
[6] Additional references
[7] New future work section
Revision 01:
[1] Editorial fixes.
Acknowledgments
This document is based on the discussions that took place within the
Lemonade working group. Acknowledgment to Dave Crocker who co-
authored the first two versions of this draft.
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
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
Maes Expires - April 2006 [Page 9]
<Lemonade and Intermediary Challenges> October 2005
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
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.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Maes Expires - April 2006 [Page 10]
