Internet DRAFT - draft-aol-imx
draft-aol-imx
INTERNET-DRAFT E. Aoki
<draft-aol-imx-00.txt> A. Wick
AOL
Expires: December 15, 2000 June 15, 2000
The IMX Architecture
Interoperability with America Online's Instant Messaging Services
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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 memo provides information for the Internet community.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
The ability to exchange instant messages and presence information
provides users with a powerful mechanism for communicating in
real-time.
This document outlines an architecture for interoperability among
Instant Messaging Systems which allows disparate systems to
exchange messages and presence information while being
relatively easy to implement and maintaining a high standard of
security and scalability.
Table of Contents
1. Introduction ......................................... 2
2. Requirements ......................................... 3
3. Terminology .......................................... 4
4. Architecture ......................................... 6
4.1 Servers and Gateways ................................ 6
Aoki & Wick [Page 1]
INTERNET-DRAFT IMX Architecture June 15, 2000
4.2 Namespace and Addressing ............................ 7
4.2.1 Address identifiers ............................... 7
4.2.2 Domains .......................................... 7
4.2.3 Server Discovery .................................. 7
4.3 Connection Management ............................... 8
4.3.1 Originating Connections ........................... 8
4.3.2 Accepting Connections ............................. 8
4.3.3 Relays ............................................ 9
4.4 Protocol Considerations ............................. 9
4.5 Additional Protocol Considerations for Presence
Information ......................................... 10
4.6 Additional Protocol Considerations for Attributes ... 10
4.7 Additional Protocol Considerations for Instant
Message Information ................................. 10
5. Instant Message Format Considerations ................ 11
6. Security Considerations .............................. 11
6.1 Objectives .......................................... 11
6.2 Assumptions ......................................... 12
6.2.1 Client Authentication ............................. 12
6.2.2 Scope ............................................. 12
6.2.2.1 Types of Attacks Within the Scope ............... 13
6.2.2.2 Types of Attacks Outside of Scope ............... 13
6.3 A Trust Model for Server to Server communications.... 14
6.3.1 The Dial-Back Mechanism ........................... 14
6.3.2 Enhanced Security ................................. 15
6.4 SPAM ................................................ 16
7. Authors' Addresses ................................... 16
8. Additional Documents ................................. 17
9. Acknowledgements ..................................... 17
10. References .......................................... 17
A. Appendix - Performance Against Objectives ............ 17
A.1 Scalability and Efficiency .......................... 18
A.2 Ease of Implementation .............................. 19
A.2.3 Reliability ....................................... 19
A.2.4 Security .......................................... 19
1. Introduction
Today's instant messaging systems are typically comprised of a
client, through which the end-user interacts, and servers which relay
information between compatible clients. Tight integration between
clients and servers allows instant messaging services to provide a
secure, reliable channel through which authentication, presence, and
messaging information is passed between users and the service.
As the number of instant messaging providers has grown, there is
increased interest in enabling IM users to exchange presence and
messaging information not only with users on their system, but
with those on other systems as well Some vendors have responded by
creating "multi-headed clients," clients which can simultaneously
communicate with servers on disparate instant messaging systems.
Aoki & Wick [Page 2]
INTERNET-DRAFT IMX Architecture June 15, 2000
Such clients achieve interoperability at a high price, however.
Since each service has its own feature set, clients may advertise
features that do not work across systems. Since each service
implements its own security model, multi-headed clients must
often resort to mechanisms that circumvent security or require
the user to provide passwords to third parties. Inconsistent
terms of service also make it difficult to enforce anti-spam
measures or encourage equitable resource sharing. And vendors
are forced to constantly upgrade clients to keep up with
changes in features and services across the instant messaging
universe.
An alternative approach is to provide a mechanism for the services
themselves to interoperate in a peering arrangement, much like the
Internet mail system works today. In such a system, the interaction
between instant messaging clients and their associated servers would
remain much as it is today, but servers could communicate with other
servers to exchange presence information, messages, or other data.
This approach helps to preserve existing models for security
and allows Instant Messaging Service providers to manage client
authentication, service policy, and privacy.
This document describes how America Online intends to develop such
an architecture to allow its services to discover other servers
(and be discovered by other servers), exchange data, and ensure
security. It also describes implications that any architecture for
interoperability may have for the spread of unsolicited instant
messaging (spam).
2. Requirements
The authors set out to design a system that would be flexible,
yet practical to implement. In that vein, many of our design goals,
listed below, are the same as or similar to those specified in
[RFC 2779], but with additional consideration paid to implementation
issues.
The primary requirements were to design a system which:
1) is scalable to hundreds of millions of instant messaging users.
2) is scalable to hundreds of thousands (or perhaps millions) of
individual instant messaging systems and domains, so every
company or ISP could have its own instant messaging system.
3) allows existing instant messaging implementations to manage
their own user namespace.
4) is self managed (like the Internet mail system) such that new
servers and new systems could be added without administration
Aoki & Wick [Page 3]
INTERNET-DRAFT IMX Architecture June 15, 2000
by some central authority and without manual administration
by other service providers.
5) initially supports at least five main end-user features:
- Requesting/Renewing/Canceling presence subscriptions
- Sending/Receiving presence notifications (in response to a
subscription)
- Routing and delivery of instant messages
- Retrieval of named user attributes (at minimum an "alias"
and current presence state)
- Retrieval of named domain attributes
6) allows traffic between users in a single instant messaging
system to stay within that system.
7) makes it possible to implement interoperability between
instant messaging systems by adding gateways to existing
systems without rearchitecting existing core systems.
8) is extensible, so new features can be added incrementally
without requiring redesign and while allowing for backwards
compatibility.
9) has a well thought-through security strategy such that:
- Messaging data or state can't be easily spoofed or replayed
by a third party
- Messaging data or state can't be easily intercepted,
hijacked, or stolen by a third party
- More advanced security measures such as end-to-end
encryption or signing can be layered on top of the initial
implementation, but are not required in the initial
implementation.
10) easily supports clients that are inside of a common company
firewall (e.g. incoming connections are often refused).
11) easily supports international usage.
12) leverages existing standards in as many places as practical.
3. Terminology
[RFC 2778] specifies a common terminology for the discussion of
Internet Messaging and Presence Protocol information; however, that
document defines terms which are considerably more granular than
are required by this document. Accordingly, this document uses
the following terms:
Aoki & Wick [Page 4]
INTERNET-DRAFT IMX Architecture June 15, 2000
Aggregator - A special kind of Gateway, which services multiple
domains and routes messages between other IMX Servers and
Servers which service a particular domain. The protocol
between the Aggregator and each Server is arbitrary. An
example of an Aggregator might be a Gateway which acts as
a front-end to multiple, privately-labeled Instant Messaging
Services.
Attributes - metadata about an End User, such as a nickname or
alias; or about a domain, such as a timeout value. Attributes
consist of a key, which is scoped at a domain, and a value.
It may be desirable to have certain attribute keys which are
global to the IMX architecture and interpreted identically
by all participating services.
Data - any of Instant Messages, Attributes, Notifications,
Subscriptions, or requests for these that are exchanged
between Servers.
End User - a human or other entity whose presence information is
reflected by the service and who can send and receive Instant
Messages through an Instant Messaging Service.
Instant Message - a short, real-time or near-real-time message
which is sent between Instant Messaging clients. While this
document does not prescribe a definition for "short," the
intent is to prevent streams of arbitrary length from
being sent as Instant Messages. This is consistent with the
definition of an INSTANT MESSAGE in [RFC 2778].
Instant Messaging Client (or Client) - a User Agent which provides
an End User with the ability to initiate and receive Instant
Messages, and request Subscriptions and receive Notifications for
Presence Information. This term is used in this document to
encompass a SENDER, INSTANT INBOX, PRESENTITY, and WATCHER in
[RFC 2778], and is roughly consistent with the generic description
of an "instant messenger" in section 2.7 of that document.
Instant Messaging Gateway (or Gateway) - a special type of
Instant Messaging Server which does not communicate directly
with Clients but sits between Servers which service a particular
domain and the world of other IMX servers. Gateways act
essentially as routers, potentially performing protocol
translation between an Instant Messaging Service's local
protocols and the IMX protocol. An example of a
Gateway would be a Server which routes messages to an
already existing, private Instant Messaging Service.
Instant Messaging Server (or Server) - an entity which
maintains Presence Subscriptions for and delivers Instant
Aoki & Wick [Page 5]
INTERNET-DRAFT IMX Architecture June 15, 2000
Messages on behalf of End Users of a given Instant Messaging
Service. Typically, Instant Messaging Clients connect
to a Server in order to send and receive Instant Messages,
Attributes, and Presence Information.
Instant Messaging Service - a collection of Instant Messaging
Servers and their associated clients which together make up
an integrated service offering. Instant Messaging Services
administer their own namespace of End User names and are
generally associated with one or more domains they serve.
Notification - a message sent from a Server to a Client to
indicate a change in the Presence Information for a given
End User. Notifications are sent only to Clients who
have previously created a Subscription to receive such
information for a particular End User. (Presence Information
may be retrieved in real-time without a Subscription by
making a request for a presence Attribute). This term
is essentially identical to the corresponding definition
in [RFC 2778].
Presence Information - information regarding the state of a
particular user. Examples might be online, offline, away,
busy, etc. Specific formats for the conveyance of Presence
Information are not specified here.
SPAM - unwanted (and typically unsolicited) Instant Messages.
Subscription - Information kept by an Instant Messaging Server
which maintains a Client's desire to be Notified when an
End User's Presence Information changes. Subscriptions are
entered by Instant Messaging Clients on behalf of End Users,
and time out if not renewed. This term is essentially
identical to the corresponding definition in [RFC 2778].
4. Architecture
The basic architecture behind IMX (Instant Messaging eXchange) is one
of multiple independent Instant Messaging Services (as exist today),
which can interoperate at the Server-to-Server, Server-to-Gateway, or
Gateway-to-Gateway level.
4.1 Servers and Gateways
Each Instant Messaging Service exchanges Data with other Services
through well known Servers or Gateways. For the purpose of this
document, Servers and Gateways are distinguished in that Servers
can be the same physical or logical entities that service Clients,
whereas Gateways essentially relay information between Servers
within a Service and those outside of it. Absent this distinction,
the terms Server and Gateway can be used interchangeably.
Aoki & Wick [Page 6]
INTERNET-DRAFT IMX Architecture June 15, 2000
Each Server is said to "service", "be responsible for", "act on
behalf of," or be "in" a domain, which is a shortcut to saying that
a Server listens for requests intended for a given Instant Messaging
Service (identified by a domain), and provides answers on behalf
of the End Users who belong to that Service. In this way, the model
is very similar to the way that SMTP servers exchange mail with other
SMTP servers.
4.2 Namespace and Addressing
4.2.1 Address identifiers
Each End User has an identifier which can be used to uniquely
address that user across various Instant Messaging Systems.
Like internet mail addresses, the identifier used to identify a
given End User consists of a local part and a domain, separated by
at-sign (@). (The at-sign is therefore a reserved character
in an Instant Messaging address).
The address used for Instant Messages may or may not be the same as
an End User's email address.
4.2.2 Domains
The domain portion of the address is assumed to be an internet
domain, compliant with [RFC 1034] and is used to identify the
Servers responsible for that domain by the process described in
Section 4.2.3.
4.2.3 Server Discovery
Servers which service a particular domain are published in DNS using
an IMX record. An IMX record is a new type of DNS record that works
similar to the MX record used by mail. It lists one or more Servers
that accept Instant Messaging connections for that particular domain.
If more than one server is listed, the originating Server picks one
of the listed servers randomly (just like with MX records) and
attempts to establish a connection. If the chosen server doesn't
respond, the originating server may attempt to connect on one of the
other listed servers.
The IMX record may also list other attributes of the connection such
as a port number.
A full specification of IMX records will follow in a separate
document.
Aoki & Wick [Page 7]
INTERNET-DRAFT IMX Architecture June 15, 2000
4.3 Connection Management
Connections between Servers use TCP for transport. They are
established on-demand by the originating Server as needed and are
semi-persistent. Connections are kept open for as long as the
originating host desires, as long as there is activity on the
connection. Connections may be closed by the receiving Server after
some period of inactivity; they would then be re-established by the
originator on-demand when next needed.
Data for multiple End Users can and likely will flow across a given
connection. Conversely, Data for a given user may flow over any
active connection that exists between the two domains and is not
guaranteed to flow over the same connection as previous requests.
If a Server handles requests for more than one domain, Data for
multiple domains may flow over a given connection. These connections
must be authenticated multiple times, once for each domain they
serve.
4.3.1 Originating Connections
A Server would establish a connection to another Server in order to
request Data on behalf of an End User within the originating server's
domain. This would include connections to send Instant Messages,
initiate or refresh Subscriptions, send Notifications, and to
request Attributes.
A Server may establish more than one connection to communicate with
another Server (i.e. for load balancing or to handle increased
traffic); however, in consideration of scalability, implementers
should take care to limit the number of such connections to a
reasonably small number. For example, it would not be appropriate
for a Server to establish one connection per End User; it would be
appropriate to establish one connection per Server process or Server
thread. In any event, a receiving server may refuse to accept
more than a given number of connections from Servers at a single
domain.
Servers will also establish connections in order to perform
authentication handshaking as specified in Section 6.3.1.
4.3.2 Accepting Connections
A Server would accept a connection from another Server in order to
receive Data for an End User within the receiving server's domain.
This would include connections to receive Instant Messages, update
or establish Subscriptions, receive Notifications, and receive
requests for Attributes.
Servers will also accept connections in order to perform
authentication handshaking as specified in Section 6.3.1.
Aoki & Wick [Page 8]
INTERNET-DRAFT IMX Architecture June 15, 2000
4.3.3 Relays
Server should only accept traffic for the domains they service.
That is, this architecture explicitly disallows relaying services
because of their possible unauthorized and unintended use (see
SPAM, section 6.4).
Instant Messaging Services will be held accountable for traffic
originating from their Servers.
4.4 Protocol Considerations
This document does not specify the details of the protocol between
Servers (the IMX protocol). However, we believe that the following
requirements should be considered in the implementation of the
protocol:
1) The protocol must have the ability to exchange protocol version
information and some protocol capability information. (4.4.1)
2) The protocol must be completely extensible without ever having to
force all other servers to upgrade. The intention is that, in
most cases, new types of data packets or request packets can be
added, and older servers can simply ignore the data or request
types that they don't understand. (4.4.2)
3) The protocol should include a means for either side to close the
connection in an orderly fashion and have the other side know that
the connection has been closed. (4.4.3)
4) The protocol should include some sort of redirection mechanism so
that the other end of an existing connection can be told to
reconnect on another IP address. (4.4.4)
This would be useful for:
- Taking an existing, active server out of service in an orderly
fashion
- Smarter load balancing beyond the capabilities of a DNS rotor.
5) The protocol needs the ability to retrieve named user
Attributes (e.g. the user's alias, UA capabilities, maximum
message length, etc...).
(4.4.5)
6) The protocol also needs the ability to retrieve named
domain-specific Attributes. For example, the timeout for a
connection or a presence subscription to expire may be a
domain-specific configuration. (4.4.6)
Aoki & Wick [Page 9]
INTERNET-DRAFT IMX Architecture June 15, 2000
7) The protocol is completely asynchronous. The connection is simply
a pipe through which requests and tagged responses flow. More
than one connection may be open between a set of servers, and more
than one request may be in process on a given connection. In
some cases, a response may not flow back on the same connection on
which it was initiated. (4.4.7)
8) The protocol should allow for responses to at least some requests
(particularly those requesting Attributes), to return on the
same connection as the request. The protocol should additionally
provide enough information in the request so that a reply can be
routed to the same Server that made the request. (4.4.8)
9) The protocol should be binary, not text. The binary format will
be records with length and type. (4.4.9)
10) Where not already specified by a chosen, existing standard, data
will be represented in UTF-8. (4.4.10)
4.5 Additional Protocol Considerations for Presence Information
When used for Subscription or Presence Information, the following
additional requirements should be considered:
1) Presence Subscription should expire in some pre-determined amount
of time (e.g. 30 minutes) if they aren't renewed. This timeout
may be different per vendor and should be published as a
domain attribute. (4.5.1)
2) Presence Notifications may be delivered over any active connection
that exists between the two domains. They are not necessarily
delivered over the same connection on which the subscription was
requested (that connection may not even exist anymore). (4.5.2)
4.6 Additional Protocol Considerations for Attributes
When used to retrieve Attributes for a user or domain, the following
additional requirements should be considered:
1) Attribute information may be sent unsolicited with Instant
Message or Presence Information so that it need not be
explicitly requested. (4.6.1)
4.7 Additional Protocol Considerations for Instant Message Information
When used for Instant Messages, the following additional requirements
should be considered:
1) As with the SMTP envelope, the To and From address flows with the
message as part of the protocol and does not need to be parsed by
Servers, Gateways, or Aggregators. (4.7.1)
Aoki & Wick [Page 10]
INTERNET-DRAFT IMX Architecture June 15, 2000
5. Instant Message Format Considerations
In order to achieve maximum flexibility, a subset of MIME [RFC 2045]
should be used for the message transfer format. Messages will consist
of headers and a body.
1) The message From and To headers are also included in the MIME
message and are required. All other headers are optional. Any
number of headers may exist. Headers such as "Content-type" and
"Content-transfer-encoding" are used if present. "Subject" is not
used. Vendors that specify additional vendor-specific headers
are strongly encouraged to use the "X-" header format.
2) Initial implementations of the architecture should support at
least two MIME types: text/plain and text/html-lite.
Text/html-lite is a strict subset of HTML with support for only
a few basic formatting tags supported (such as <B>...</B>,
<I>...</I>, etc...).
No additional attempt is made to describe text/html-lite in this
document.
3) Very long lines are permitted. Text/plain messages are not
prewrapped to any particular column width. A paragraph is sent
as one long line. It is the receiving Client's responsibility
to wrap the message for proper display. It is important that all
servers support this correctly because Instant Messaging user
interfaces are often used in a small screen form factor where
appropriate wrapping substantially increases the usability.
The small screen requirement comes about either because the
Client runs on a small screen device or because the user wishes
to devote only a small piece of screen real estate to the Client
user interface.
6. Security Considerations
6.1 Objectives
[RFC 2779] specifies in detail a series of requirements for security
in an Instant Messaging protocol. In developing this architecture,
the authors also considered the following objectives in order to
ensure practicality of implementation:
1) The architecture should be straightforward to implement and
administer and be freely exportable.
2) The system, including the relationship between arbitrary
Instant Messaging Services, should be self-managed, with no
centralized authority required to administer the security scheme.
Aoki & Wick [Page 11]
INTERNET-DRAFT IMX Architecture June 15, 2000
3) The security scheme should account for a basic level of
security but be easily extensible so that some Services may
implement a higher degree of security.
4) In order to address these objectives (1-3), the intent is
to authenticate connections between Servers, not individual
exchanges of Data.
5) In keeping with the objectives of (3), it should be possible,
but not required, to support end-to-end encryption and/or
signing. (End-to-end encryption refers to data encrypted
by the sending Client and decrypted at the recipient's Client).
6) In keeping with the objectives of (3), it should be possible,
but not required, to support the use of advanced security
measures such as SSL or certificate exchange between Servers.
7) User passwords should never be exchanged in a Server to
Server communication.
The overarching intent behind these objectives is to provide a
system which would offer substantially higher security than
Internet email, yet offer a basic level of security that could
be easily and rapidly implemented. At the same time, the model
would be extensible enough to allow for increased security should
users, vendors, or other entities demand it.
6.2 Assumptions
6.2.1 Client Authentication
Because this architecture specifies a Server to Server protocol, it
does not specify or recommend any mechanism for authenticating
Clients to a Server. Each Instant Messaging Service is held
responsible for security between Clients and Servers, including
preventing one End User from impersonating another.
In all discussions in this section, this document assumes that a
given Server can be trusted when it represents that Data originates
from a given End User.
6.2.2 Scope
Each individual Instant Messaging Service is responsible for making
sure that a given End User is not an impersonator. Therefore, the
principal problem this document tries to solve is to ensure that
Data sent and received on behalf of an End User in a given domain
is actually originating from and/or being sent to Servers in that
domain.
Aoki & Wick [Page 12]
INTERNET-DRAFT IMX Architecture June 15, 2000
Additionally, the architecture seeks to protect against a spoofing
attack where one Server pretends to issue Data on behalf of users
in a domain that it does not represent.
6.2.2.1 Types of Attacks Within the Scope
The following types of attacks are explicitly covered by
the proposed architecture.
1) Breach of Presence Privacy - Spoofing an End User who is
requesting Presence Information (or Attributes). This form
of security becomes especially important if a service supports
restrictions on who can and can not retrieve Presence Information
(or Attributes) for a given End User. This is essentially the
requirement 5.1.1 in [RFC 2779], where A and B are SERVERS
instead of non-ADMINISTRATOR PRINCIPALs.
2) False Presence - Spoofing state about a given End User (e.g.
if User A in a given domain is subscribed to receive Presence
Information for User B in another domain, it is not possible
for a User C to send Notifications with User B's Presence
Information to User A). This is essentially the requirement
5.2.4 in [RFC 2779], where users A and B are authenticated
ENTITIES in separate DOMAINS.
3) Spoofing Sender - Spoofing the From address for a given Instant
Message (e.g. User C in a given domain sends an Instant Message
to User B purporting to be User A). This is essentially the
requirement 5.4.3 in [RFC 2779], where A and B are authenticated
ENTITIES in separate DOMAINS.
4) Stealing Data - Hijacking Data intended for a given End User and
redirecting it somewhere else. (e.g. User A sends an Instant
Message to User B, but it instead is directed to User C). This
is essentially requirements 5.3.3 and 5.4.6 in [RFC 2779], where
A and B are authenticated ENTITIES in separate DOMAINS.
6.2.2.2 Types of Attacks Outside of Scope
For practical reasons (see Objectives, 6.1), a "standard"
implementation of security as defined in this document does not
protect against the following types of attacks:
- DNS Hijacking
- Man-in-the-middle attacks
- Eavesdropping or packet snooping
However, an advanced implementation of security may protect against
these within the specified architecture (see section 6.3.2).
Aoki & Wick [Page 13]
INTERNET-DRAFT IMX Architecture June 15, 2000
6.3 A Trust Model for Server to Server communications
This document therefore proposes the following architecture for
establishing trust between Servers:
1) Servers will trust DNS for all outgoing connections. If a Server
establishes a connection from Domain A to Domain B, it should be
relatively certain that data sent over that connection is actually
going to Domain B. The only situations where that assumption
would not be true would be if the entirety of Domain B were
hijacked, and that is explicitly not covered by this model (see
6.2.2.2).
2) Incoming connections to a Server are not trusted (since they could
originate anywhere). Incoming connections are authenticated by
using a mechanism referred to as "dial-back" (see 6.3.1), which
establishes an outbound connection to the originating Server to
authenticate the Server which makes the inbound connection.
3) Once a connection is established and trusted, it is trusted for
the life of the connection.
6.3.1 The Dial-Back Mechanism
The Dial-Back mechanism is so-named after the (now somewhat old)
concept which goes something like this:
- If User A calls User B, then User A trusts that she is talking to
User B because she made the call.
- If User A calls User B, User B does not trust that he is talking to
User A, since anyone could call User B pretending to be User A.
- If User A calls User B and provides some secret, User B can call
User A on another line and provide that same secret. This ensures
that User A and User B are the same on both calls (since they
have exchanged the secret), and that Users A and B trust each other
(since each user originated the call on which they are providing
the information). Therefore, both lines can be trusted equally.
It is fairly straightforward to extend this concept to the exchange
of Data between Servers. When a Server at Domain A accepts a
connection which supposedly originates from Domain B, it must
first authenticate that connection as follows:
1) The incoming connection from Domain B (call this Connection 1)
contains an initial token from Domain B. This token is purely for
Domain B's implementation convenience and can be anything Domain B
wants it to be (see Implementation Note, below).
Aoki & Wick [Page 14]
INTERNET-DRAFT IMX Architecture June 15, 2000
2) Domain A then creates an outgoing connection to Domain B (call
this Connection 2). In establishing this connection, Domain A
uses no information passed in as part of the original request on
Connection 1 (except, of course, the name of Domain B). That is,
Domain A will use its own DNS resolution to establish its
connection to Domain B and will not honor an IP address sent in
across Connection 1, for example.
3) After establishing Connection 2, Domain A passes to Domain B two
pieces of data: the token originally given to Domain A by Domain
B, and a short-lived secret coined by Domain A.
4) When Domain B receives the secret over Connection 2 from Domain A,
it sends the secret back to Domain A over Connection 1.
5) Upon validation of its secret, the Server at Domain A knows that
the Connection 1 shares knowledge with Connection 2 and therefore
can be assumed to exist between the same two points. Connection
1 and Connection 2, then can be trusted equally for the exchange
of information.
6) If Connection 1 were trying to spoof Domain B, it would not
receive Connection 2 from Domain A and would therefore not be able
to obtain the necessary secret required to authenticate
Connection 1.
Implementation Note: Domain B may want, at a minimum, to encode
specific information about the requesting server, process, or thread
as part of the token it passes to Domain A. In this way, Domain B
can correlate Connection 1 with Connection 2.
6.3.2 Enhanced Security
The "Dial-Back" approach protects against all forms of attacks except
man-in-the-middle attacks, packet snooping, and DNS hijack, and
is therefore consistent with the objectives. Additionally, because
many different End Users' Data will flow over a single connection,
and a given End User's Data may be spread across multiple
connections, the only way to actually spoof an End User is to
effectively take over the entire domain. While that's certainly
possible under this architecture, it's not very likely and would
certainly be easily noticed.
If it became a requirement to protect against man-in-the-middle
and packet snooping attacks, encrypted SSL connections can be
established between the Servers without any change to the
architecture.
If it became a requirement to protect against DNS hijacking, digital
certificates with a known trust hierarchy could be used to
authenticate Servers as part of the dial-back process.
Aoki & Wick [Page 15]
INTERNET-DRAFT IMX Architecture June 15, 2000
6.4 SPAM
When compared to Internet email, this proposal has the following
benefits in fighting SPAM:
1) The source domain for an Instant Message is authenticated using
the dial-back mechanism so it is not possible to easily spoof a
domain. This doesn't mean it's not easy for a malicious entity
to set up his own Instant Messaging Service and launch SPAM from
it, but that domain will eventually get blocked as a SPAM domain.
It does mean, however, that one can't easily spoof messages from
a high profile domain that one doesn't own.
2) There is no relaying in the protocol so there can be no accidental
"open relay" servers for SPAMers to leverage.
3) Instant Messaging is generally not a store and forward system so
a SPAMer would have to find the target online in order to send out
a SPAM message. If a system supports offline Instant messages
(which essentially creates a store and forward system), that
system may need to implement some additional protections.
4) Early implementations should deploy rate limiting on all user
accounts so any automated delivery mechanisms (e.g. agents that
send out Instant Messages faster than a normal person would type)
will get blocked. Exceptions may be made for approved
notification services (e.g. an electronic trading company that
lets End Users subscribe to stock price alerts), but the default
will be that all accounts are rate limited.
5) Instant Messaging Clients may choose to automatically restrict
or permit Instant Messages based on
- Sender's domain
- Sender's fully qualified address
- Recipient's buddy or contact list
- Other, vendor specific criteria
7. Authors' Addresses
Edwin Aoki
AOL
501 E. Middlefield Rd., MV-102
Mountain View, CA 94043
USA
aoki@aol.net
Aoki & Wick [Page 16]
INTERNET-DRAFT IMX Architecture June 15, 2000
Andy Wick
AOL
22000 AOL Way
Dulles, VA 20166
USA
wick@aol.net
8. Additional Documents
The following protocols and/or concepts described in this document
will likely need additional explanation in additional documents:
- Detailed information about the IMX protocol
- The IMX DNS record
- The text/html-lite MIME type
9. Acknowledgements
Many thanks are due to the engineering and management team of
America Online for their support in drafting this document.
Particular credit is due to Eric Bosco and John Friend for their
help in developing many of the ideas reflected in this paper.
10. References:
[RFC 822] Crocker, D., "Standard for the Format of ARPA Internet
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[RFC 2779] Day, M., Aggarwal, S., Mohr, G. and Vincent, J,
"Instant Messaging / Presence Protocol Requirements",
RFC 2779, February 2000.
[RFC 2778] Day, M., Rosenberg, J. and H. Sagano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[RFC 2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
A. Appendix - Performance Against Objectives
In designing the specification for this architecture, the authors
tried to strike a balance between practicality of implementation
and the needs of End Users and Instant Messaging System operators.
This section describes how, in the authors' view, the architecture
described meets the requirements set out in Section 2.
Aoki & Wick [Page 17]
INTERNET-DRAFT IMX Architecture June 15, 2000
A.1 Scalability and Efficiency
It is obviously very important that servers implementing this
architecture be able to scale to handle large numbers of users,
messaging systems (domains) and requests across the protocol.
While avoiding the discussion of how to build a Server which
can handle a large number of Client requests (i.e. users),
the architecture itself should be scalable to large numbers
of systems and efficient for heavy use, for the following
reasons:
1) The authentication mechanism is lightweight, and authentication
needs to occur only at the time a connection is established
2) Once authenticated, connections are basically stateless,
so an implementation can easily use multiple hosts to split
the load.
3) There are a variety of ways to split the load for incoming
connections across multiple hosts:
- Multiple hosts can be specified in the IMX record
- The load can be split using DNS round robin
- The load can be split using a load balancing router
4) Because the architecture is Server to Server, Instant
Messaging System vendors can optimize traffic within their
own systems and use the interoperability architecture as
needed for traffic across systems.
5) The protocol is very lightweight. The Gateway Servers are not
being asked to do anything that's CPU intensive; mostly they
are simply acting as a protocol translator between the public
IMX protocol and the internal state of the Instant Messaging
System.
6) The architecture works over semi-persistent connections that
stay alive as long as there is traffic on them. This allows
the traffic for many different users to flow over a single socket.
7) The protocol is envisioned to be very efficient and not "chatty".
Each operation is self contained - fully encapsulating a given
request in a single protocol request with a single protocol
response.
Aoki & Wick [Page 18]
INTERNET-DRAFT IMX Architecture June 15, 2000
A.2 Ease of Implementation
1) The architecture specifies a structure that allows vendors to
quickly provide users with the benefit they most want - ability
to message across systems, without precluding advanced features
later.
2) There are three ways to participate in interoperability,
allowing for all existing instant messaging products to
choose the model which best suits its needs:
- By having the system's Servers (the ones to which
individual clients connect) be public and communicate
with other systems,
- By having each system's servers communicate through a
Gateway which translates between a vendor's client-server
protocol and the interoperability protocol, or
- By having each system's Servers communicate via some
private Server-to-Server protocol to an Aggregator, which
translates between that protocol and the interoperability
protocol.
3) It should be very straightforward to implement this protocol in
a set of Gateway Servers that connect an existing system to the
outside world, allowing vendors to leverage existing investments
in technology and resources.
4) It is not anticipated that the Gateway Servers would need to hold
any additional state beyond what a regular Instant Messaging
System is already holding
A.2.3 Reliability
1) The stateless connections allow a given Server to go down,
restart and resume processing of requests without a lengthy
restart or connection building process.
2) The connect-on-demand capability makes for automatic recovery
when a connection or Server goes down.
A.2.4 Security
1) Even without SSL, digital certificates, or end-to-end encryption
the architecture provides for a system which is far more secure
than e-mail.
Aoki & Wick [Page 19]
INTERNET-DRAFT IMX Architecture June 15, 2000
2) Instant Messaging Service providers are responsible for the
enforcement of security within their own domain, allowing them
to use the most appropriate level of security for their user
base.
3) Likely attacks on the system are difficult, noticeable, and can
not easily target an individual account.
4) The architecture provides for vendors to implement more advanced
security if appropriate.
5) The authenticated connection approach makes it more difficult for
anonymous SPAM to enter the system.
Full Copyright Statement
"Copyright (C) The Internet Society (2000). All Rights Reserved.
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 implmentation 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.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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."
Aoki & Wick [Page 20]
