Internet DRAFT - draft-ietf-lemonade-intermediary-challenges
draft-ietf-lemonade-intermediary-challenges
<Lemonade and Intermediary Challenges> February 2005
Lemonade
Internet Draft: Challenges of Intermediaries S. H. Maes
Document: draft-ietf-lemonade-intermediary- D. Crocker
challenges-00.txt
Expires: August 2005 February 2005
Lemonade and the challenges of Intermediaries
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 - August 2005 [Page 1]
<Lemonade and Intermediary Challenges> February 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.................... 4
2.3.1. HTTP / HTTPS firewalls........................ 4
2.3.2. Time-outs..................................... 4
2.3.3. Deployment challenges......................... 4
3. Analysis................................................ 5
4. Initial considerations: A wish list for Lemonade........ 5
Security Considerations.................................... 6
References................................................. 6
Acknowledgments............................................ 6
Authors Addresses.......................................... 6
Intellectual Property Statement............................ 7
Full Copyright Statement................................... 7
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].
In that document, it was pointed out that numbers of (mobile) e-mail
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).
In addition, many intermediaries found in mobile deployments between
clients and servers are often set with limited timeout for pinholes,
sessions etc...
Maes Expires - August 2005 [Page 2]
<Lemonade and Intermediary Challenges> February 2005
2.
Description of the problem
2.1.
Mobile e-mail with IMAP4, POP3 and SMTP
Following the analysis presented in [MEMAIL], 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:
- 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.
Maes Expires - August 2005 [Page 3]
<Lemonade and Intermediary Challenges> February 2005
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.
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 [LEMONADE] a quick reconnect scheme [RECONNECT].
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] 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. It is very difficult to assess such time out in general.
2.3.3. Deployment challenges
Maes Expires - August 2005 [Page 4]
<Lemonade and Intermediary Challenges> February 2005
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
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.
Maes Expires - August 2005 [Page 5]
<Lemonade and Intermediary Challenges> February 2005
- Guidelines for implementation and deployement of intermediaries to
mitigate the issues identified in this document.
Security Considerations
Security considerations are discussed throughout section 2 with
respect to firewalls, confidentiality, integrity and the risk posed
by intermediaries.
<< EditorÆs note: More to be added as document expands.>>
References
[LEMONADE] 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).
[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.
Acknowledgments
This document is based on the discussions that took place within the
Lemonade working group.
Authors Addresses
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
Maes Expires - August 2005 [Page 6]
<Lemonade and Intermediary Challenges> February 2005
M/S 4op634
Redwood Shores, CA 94065
USA
Phone: +1-650-607-6296
Email: stephane.maes@oracle.com
Dave Crocker
<<EditorÆs note: Details to be completed >>
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.
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 2004. 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
Maes Expires - August 2005 [Page 7]
<Lemonade and Intermediary Challenges> February 2005
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 - August 2005 [Page 8]
