Network Working Group L. Dusseault
Internet-Draft Xythos
Expires: August, 2003 February 23, 2003
Requirements for Server-to-Server Event Pipeline Protocols
draft-dusseault-s2s-event-reqs
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 Internet-Draft will expire on May 28, 2003.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
Server-to-server event pipelines are required in situations where an
event source generates events for a number of end-users (or simply
generates events without an idea of who the end recipients might be),
and sends these events to an event or notification aggregator
service. These kinds of event source servers are common in messaging
(for example, voice messaging servers and calendar servers might send
events to a user's main messaging server or to a single-purpose
notification server). A general set of requirements is outlined here
for the server-to-server aspect of these kinds of scenarios.
Dusseault Expires August 2003 [Page 1]
Internet-Draft Server Event Pipeline Requirements February 2003
1. Introduction
The need for this requirements document arose in the VPIM and
Lemonade working groups in 2002, where a protocol for server-to-
server messaging events was being considered. Such a protocol cannot
be considered in isolation: it must be considered together with other
protocols and applications with which the protocol interacts. This
includes the nature of the application server generating events, the
kind of events that may be generated, and other protocols that may be
used later to deliver notifications. It is also important to have a
basic idea how this protocol will be used and extended beyond its
original description.
This document considers security requirements, internationalization
requirements, and architectural requirements. Also, it considers
notification info-set requirements. The notification info-set refers
to the set of information that must be present or can be generated
for an event notification so that it can be delivered using another
protocol without having to make inaccurate guesses at any important
information. For example, it must be possible to tell what host an
event arises on so that when the event is delivered the end
application knows what host to go to for more information about the
event. Since the source machine may be host multiple site names
which all use the same event pipeline, this information must be in
the event notification. This and other possible examples will be
discussed later.
The security requirements section includes some discussion of the
threat model.
Examples from unified messaging are typically used (voice mail,
email, calendaring) but occasionally examples from more speculative
areas are used to illustrate the need for a certain requirement.
Here is a representative list of the kinds of application problems
IETF groups are would like to solve related to notifications.
o SNAP proposal in lemonade and vpim working groups, intended for
email/voice mailbox event delivery from source server to
aggregation server
o RFC 3265 [1] specifies SIP notifications
o WebDAV WG has seen a specific proposal for events (GENA) relating
to resources. For example, authors may be notified when their
document becomes unlocked.
o CalSched WG has discussed notifications for appointment reminders.
Dusseault Expires August 2003 [Page 2]
Internet-Draft Server Event Pipeline Requirements February 2003
o HTTP/OPES/WEBI WG has discussed notifications of web cache timeout
events.
o XMPP involves notifications of presence changes. Instant messages
can almost be seen as events.
o LDAP-EXT WG has discussed a notification protocol
o IPP WG has discussed requirements for a printing event
notification
Dusseault Expires August 2003 [Page 3]
Internet-Draft Server Event Pipeline Requirements February 2003
2. Architecture Considerations
2.1 Connection Characteristics
A server-to-server messaging event pipeline can be used to aggregate
notifications for eventual delivery to end-user. It can also be used
to update information on an application server. For example,
notifications of new voice mail events could arrive at a regular
email server, and the regular email server could store a count of new
voice mail events until the user logs on and asks for all new
messages. Multiple event source servers, of the same type or
different types, could all set up a pipeline to the source sink
server.
If the messaging servers all have accounts for the same users, then
the pipeline is likely to carry a large number of events. Modern
email servers can handle 10,000 concurrent users, and people can
recieve 300 new email a day, thus 3 million new email events can be
generated daily, before even counting other types of email events, or
other types of events (voice messages, calendaring, instant messaging
and presence). This kind of load must be assumed for a server-to-
server messaging event protocol.
The server-to-server pipeline could be efficiently maintained as an
open TCP connection, to avoid recurring connection startup costs.
Privacy and authentication could be ensured with a transport layer
encryption protocol like TLS [REF]. A TCP connection also allows for
somewhat simpler acknowledgement of received events, assuming acks
are required.
UDP could be considered for efficient delivery of small messages, but
in the absence of IPSEC, some kind of encryption would have to be
used to protect privacy. A per-UDP-packet encryption mechanism like
S/MIME is probably unusable due to length limitations, but it would
be possible to define an encryption mechanism that encrypted each
packet using the same shared secret. However, this might not provide
authorization/authentication, unless provisioning work was used to
configure the servers to share the secret and not connect to servers
without such a secret. Note that with UDP acks are somewhat more
complicated because the event source server needs to correlate acks
to events that may have been sent a while ago even if more recent
events have already been acked.
TODO: think more about TCP/UDP and per-packet encryption.
Whether TCP or UDP is used, a request/response model protocol is
likely inappropriate. Request/response protocols rely very little on
state between requests, so instead state-like information is repeated
Dusseault Expires August 2003 [Page 4]
Internet-Draft Server Event Pipeline Requirements February 2003
on each request. In this application, some state information is
likely to change only rarely if ever. For example, HTTP requires
headers like content-length and content-type on every single request.
In an event pipeline, content-type (of the notification itself) will
likely be unnecessary or rarely necessary.
2.2 ACKs
Are acknowledgements required?
2.3 Interoperation with other Notification systems
A server receiving a large number of notifications relating to many
users mailboxes may be able to deal with those notifications itself,
but may also need to pass those notifications on to the end-user's
client at some point. This may result in some need for consistent or
consistently transformable addresses. Email addresses can probably
be used in some messaging scenarios, but what about other addresses?
What if the server receiving the notifications is not an email server
but another kind of notification aggregator? Can a SIP event server
receive a "new voice message" notification and know what address to
use to set up a replay session with a SIP client?
2.4 Subscriptions
Is it a requirement that the recipient of notifications be able to
choose which kinds are required? This would allow the server to
filter out notifications for accounts that are inactive, and
notifications of uninteresting types. It might greatly reduce the
quantity of notifications used in the system.
Another possible advantage of subscriptions is that if a subscription
ID is assigned, the sender of the notification can more efficiently
identify the context of the notification for the recipient.
Dusseault Expires August 2003 [Page 5]
Internet-Draft Server Event Pipeline Requirements February 2003
3. Security Requirements
3.1 Privacy
Messaging events, and any other event having to do with user account
activity, and in fact many events of many kinds, may have sensitive
or private information. The event may only contain the information
that an email arrived from a certain address at a certain time with a
certain subject, but even this much information can be considered
sensitive.
A protocol for event notification MUST require minimum-to-implement
privacy protection mechanisms. It is not sufficient to leave these
mechanisms up to implementors, because two independent
implementations must have at least one shared privacy mechanism in
order to be able to interoperate and still protect privacy.
3.2 Integrity
Event integrity considerations include the following threats
o An attacker might want to cause certain events not to get
delivered, and for this lack of delivery to go unnoticed.
o An attacker might generate false event notifications which are
received and treated as legitimate events.
o An attacker might cause duplicate delivery of otherwise legitimate
event notifications. The danger is if the duplicate delivery goes
unnoticed. For example, a legitimate event signaling the order of
expensive equipment might get delivered several times appearing as
separate events.
o Event notifications might be changed en route.
A protocol for event notification MUST protect from event
notification integrity attacks by requiring a minimum-to-implement
integrity protection mechanism. Notice also that the architecture
MUST protect the notification aggregator from impersonation attacks,
which allow streams of false events to be inserted into the system by
pretending to be a legitimate event source.
It's probably not possible to protect completely from an attacker
causing events to be lost (the attacker might be able to cause the
connection between the servers to go down). However, it should not
be possible for events to be removed from an otherwise successfully
maintained connection.
Dusseault Expires August 2003 [Page 6]
Internet-Draft Server Event Pipeline Requirements February 2003
3.3 Authentication
Authentication must be considered in order to ensure privacy and
protect from integrity attacks. It may be necessary for a
notification aggregation server to provide authentication for the end
user in order to prove that access to certain kinds of event
information is allowed.
3.4 Authorization
There are a number of potential authorization issues.
o Permission to subscribe to certain information: e.g. is the
notification aggregation server allowed to subscribe to a certain
user's calendar events
o Permission to send events: e.g. is the event source server
allowed to open a pipeline and send events to the event sink
server
o Permission to route events to a particular user: e.g. is the
event source server allowed to send events to a particular user
via a notification aggregation server
Some of these authorization issues may be mitigated by opening a
connection in a certain direction. For example, if a notification
aggregation server opens a connection to the event source server, it
can be assumed the event source server is allowed to send events over
this connection.
Sometimes authorization issues are dealt with as a matter of
provisioning. It is assumed that the administrator configures the
source to send events to the sink, and configures the sink to receive
events from the source. However, if this is the approach used, the
protocol specification MUST discuss how an implementation should
behave such that provisioning does solve the problem.
Dusseault Expires August 2003 [Page 7]
Internet-Draft Server Event Pipeline Requirements February 2003
4. Internationalization Requirements
4.1 Character Set
An event notification protocol must support Unicode (must require
implementations to support Unicode) in order to convey information
about events. For example, the name of a WebDAV resource that
becomes unlocked (and generates an unlock event) might be Unicode).
4.2 Language Negotiation
An event notification may not need language negotiation. The events
occur with given text, with or without language negotiation. The
event sink server may not even be capable of determining the language
preference for an event if the event is going to be multiplexed to
multiple users.
Because some languages share some unicode characters, an event
notification protocol will sometimes need to convey the language of
human-readable strings. The language information allows proper
selection of font for display.
In order to minimize language issues, error codes should be machine
parsable.
Dusseault Expires August 2003 [Page 8]
Internet-Draft Server Event Pipeline Requirements February 2003
5. Extensibility Requirements
5.1 Event Type Names
The most likely path for extensibility is simply to define new event
types, new event names, and the information that goes along with
events. By "event name" I mean the name given to a type of event so
that the event sink server can tell what type of event it is. Thus
the event name could be something like "new-email" in the namespace
"http://www.example.com/namespaces/email-application" (a XML QName or
Qualified Name [REF]).
Event names must be machine readable so that applications can
dispatch based on event type.
Event names should be extensible by any number of independently
operating groups without serious risk of collision. For example, the
WebDAV group should be able to define a resource unlock event, and
not have to coordinate with other groups that might wish to define an
event for unlocking other kinds of objects. This problem could be
solved with use of XML namespaces, because each group can
independently define its own namespace with certain rules that make
duplicate namespaces unlikely, then the group can define event names
that are qualified with that namespace.
Dusseault Expires August 2003 [Page 9]
Internet-Draft Server Event Pipeline Requirements February 2003
References
[1] Roach, A., "SIP-Specific Event Notification", RFC 3265, June
2002.
Author's Address
Lisa Dusseault
Xythos Software, Inc.
2064 Edgewood Dr.
Palo Alto, CA 94303
US
EMail: lisa@xythos.com
Dusseault Expires August 2003 [Page 10]
Internet-Draft Server Event Pipeline Requirements February 2003
Full Copyright Statement
Copyright (C) The Internet Society (2002). 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 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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dusseault Expires August 2003 [Page 11]