Internet Engineering Task Force SIMPLE WG
Internet Draft J. Rosenberg
dynamicsoft
draft-ietf-simple-winfo-package-05.txt
January 31, 2003
Expires: July 2003
A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
This document defines the watcher information template-package for
the SIP event framework. Watcher information refers to the set of
users subscribed to a particular resource within a particular event
package. Watcher information changes dynamically as users subscribe,
unsubscribe, are approved, or are rejected. A user can subscribe to
this information, and therefore learn about changes to it. This event
package is a template-package because it can be applied to any event
package, including itself.
J. Rosenberg [Page 1]
Internet Draft Watcher Information January 31, 2003
Table of Contents
1 Introduction ........................................ 3
2 Terminology ......................................... 3
3 Usage Scenarios ..................................... 4
3.1 Presence Authorization .............................. 4
3.2 Blacklist Alerts .................................... 5
4 Package Definition .................................. 5
4.1 Event Package Name .................................. 5
4.2 Event Package Parameters ............................ 6
4.3 SUBSCRIBE Bodies .................................... 6
4.4 Subscription Duration ............................... 6
4.5 NOTIFY Bodies ....................................... 7
4.6 Notifier Processing of SUBSCRIBE Requests ........... 7
4.7 Notifier Generation of NOTIFY Requests .............. 8
4.7.1 The Subscription State Machine ...................... 8
4.7.2 Applying the State Machine .......................... 11
4.8 Subscriber Processing of NOTIFY Requests ............ 12
4.9 Handling of Forked Requests ......................... 12
4.10 Rate of Notifications ............................... 13
4.11 State Agents ........................................ 13
5 Example Usage ....................................... 13
6 Security Considerations ............................. 16
6.1 Denial of Service Attacks ........................... 16
6.2 Divulging Sensitive Information ..................... 17
7 IANA Considerations ................................. 17
8 Acknowledgements .................................... 18
9 Authors Addresses ................................... 18
10 Normative References ................................ 18
11 Informative References .............................. 18
J. Rosenberg [Page 2]
Internet Draft Watcher Information January 31, 2003
1 Introduction
The SIP event framework is described in RFC 3265 [1]. It defines a
generic framework for subscription to, and notification of, events
related to SIP systems. The framework defines the methods SUBSCRIBE
and NOTIFY, and introduces the notion of a package. A package is a
concrete application of the event framework to a particular class of
events. Packages have been defined for user presence [5], for
example.
This draft defines a "template-package" within the SIP event
framework. A template-package has all the properties of a regular SIP
event package. However, it is always associated with some other event
package, and can always be applied to any event package, including
the template-package itself.
The template-package defined here is for watcher information, and is
denoted with the token "winfo". For any event package, such as
presence, there exists a set (perhaps an empty set) of subscriptions
that have been created or requested by users trying to ascertain the
state of a resource in that package. This set of subscriptions
changes over time as new subscriptions are requested by users, old
subscriptions expire, and subscriptions are approved or rejected by
the owners of that resource. The set of users subscribed to a
particular resource for a specific event package, and the state of
their subscriptions, is referred to as watcher information. Since
this state is itself dynamic, it is reasonable to subscribe to it in
order to learn about changes to it. The watcher information event
template-package is meant to facilitate exactly that - tracking the
state of subscriptions to a resource in another package.
To denote this template-package, the name is constructed by appending
".winfo" to the name of whatever package is being tracked. For
example, the set of people subscribed to presence is defined by the
"presence.winfo" package.
2 Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and
indicate requirement levels for compliant implementations.
This document fundamentally deals with recursion - subscriptions to
subscriptions. Therefore, the term "subscription" itself can be
confusing in this document. To reduce confusion, the term
"watcherinfo subscription" refers to a subscription to watcher
information, and the term "watcherinfo subscriber" refers to a user
J. Rosenberg [Page 3]
Internet Draft Watcher Information January 31, 2003
that has subscribed to watcher information. The term "watcherinfo
notification" refers to a NOTIFY request sent as part of a
watcherinfo subscription. When the terms "subscription",
"subscriber", and "notification" are used unqualified, they refer to
the "inner" subscribers, subscriptions, and notifications - those
that are being monitored through the watcherinfo subscriptions. We
also use the term "watcher" to refer to a subscriber to the "inner"
resource. Information on watchers is reported through watcherinfo
subscriptions.
3 Usage Scenarios
There are many useful applications for the watcher information
template-package.
3.1 Presence Authorization
The motivating application for this package is presence
authorization. When user A subscribes to the presence of user B, the
subscription needs to be authorized. Frequently, that authorization
needs to occur through direct user intervention. For that to happen,
B's software needs to become aware that a presence subscription has
been requested. This is supported through watcher information. B's
client software would SUBSCRIBE to the watcher information for the
presence of B:
SUBSCRIBE sip:B@example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
From: sip:B@example.com;tag=123s8a
To: sip:B@example.com
Call-ID: 9987@pc34.example.com
Max-Forwards: 70
CSeq: 9887 SUBSCRIBE
Contact: sip:B@pc34.example.com
Event: presence.winfo
The policy of the server is such that it allows B to subscribe to its
own watcher information. So, when A subscribes to B's presence, B
gets a notification of the change in watcher information state:
NOTIFY sip:B@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna66g
From: sip:B@example.com;tag=xyz887
To: sip:B@example.com;tag=123s8a
J. Rosenberg [Page 4]
Internet Draft Watcher Information January 31, 2003
Call-ID: 9987@pc34.example.com
Max-Forwards: 70
CSeq: 1288 NOTIFY
Contact: sip:B@server.example.com
Event: presence.winfo
Content-Type: application/watcherinfo+xml
Content-Length: ...
sip:A@example.com
This indicates to B that A has subscribed, and that the subscription
is pending (meaning, it is awaiting authorization). B's software can
alert B that this subscription is awaiting authorization. B can then
set policy for that subscription.
3.2 Blacklist Alerts
Applications can subscribe to watcher information in order to provide
value-added features. An example application is "blacklist alerts".
In this scenario, an application server maintains a list of known
"bad guys". A user, Joe, signs up for service with the application
provider, presumably by going to a web page and entering in his
presence URI. The application server subscribes to the watcher
information for Joe's presence. When someone attempts to SUBSCRIBE to
Joe's user presence, the application learns of this subscription as a
result of its watcher info subscription. It checks the watcher's URI
against the database of known bad guys. If there is a match, it sends
email to Joe letting him know about this.
For this application to work, Joe needs to make sure that the
application is allowed to subscribe to his presence.winfo.
4 Package Definition
This section fills in the details needed to specify an event package
as defined in Section 4.4 of RFC 3265 [1].
4.1 Event Package Name
J. Rosenberg [Page 5]
Internet Draft Watcher Information January 31, 2003
RFC 3265 [1] requires package definitions to specify the name of
their package or template-package.
The name of this template-package is "winfo". It can be applied to
any other package. Watcher information for any package foo is denoted
by the name "foo.winfo". Recursive template-packaging is explicitly
allowed (and useful), so that "foo.winfo.winfo" is a valid package
name.
4.2 Event Package Parameters
RFC 3265 [1] requires package and template-package definitions to
specify any package specific parameters of the Event header field.
No package specific Event header field parameters are defined for
this event template-package.
4.3 SUBSCRIBE Bodies
RFC 3265 [1] requires package or template-package definitions to
define the usage, if any, of bodies in SUBSCRIBE requests.
A SUBSCRIBE request for watcher information MAY contain a body. This
body would serve the purpose of filtering the watcherinfo
subscription. The definition of such a body is outside the scope of
this specification. For example, in the case of presence, the body
might indicate that notifications should contain full state every
time something changes, and that the time the subscription was first
made should not be included in the watcherinfo notifications.
A SUBSCRIBE request for a watcher information package MAY be sent
without a body. This implies the default watcherinfo subscription
filtering policy has been requested. The default policy is:
o Watcherinfo notifications are generated every time there is
any change in the state of the watcher information.
o Watcherinfo notifications triggered from a SUBSCRIBE contain
full state (the list of all watchers that the watcherinfo
subscriber is permitted to know about). Watcherinfo
notifications triggered from a change in watcher state only
contain information on the watcher whose state has changed.
Of course, the server can apply any policy it likes to the
subscription.
4.4 Subscription Duration
J. Rosenberg [Page 6]
Internet Draft Watcher Information January 31, 2003
RFC 3265 [1] requires package definitions to define a default value
for subscription durations, and to discuss reasonable choices for
durations when they are explicitly specified.
Watcher information changes as users subscribe to a particular
resource for some package, or their subscriptions time out. As a
result, the state of watcher information can change very dynamically,
depending on the number of subscribers for a particular resource in a
given package. The rate at which subscriptions time out depends on
how long a user maintains its subscription. Typically, watcherinfo
subscriptions will be timed to span the lifetime of the subscriptions
being watcher, and therefore range from minutes to days.
As a result of these factors, it is difficult to define a broadly
useful default value for the lifetime of a watcherinfo subscription.
We arbitrarily choose one hour. However, clients SHOULD use an
Expires header field to specify their preferred duration.
4.5 NOTIFY Bodies
RFC 3265 [1] requires package definitions to describe the allowed set
of body types in NOTIFY requests, and to specify the default value to
be used when there is no Accept header field in the SUBSCRIBE
request.
The body of the watcherinfo notification contains a watcher
information document. This document describes some or all of the
watchers for a given package, and the state of their subscriptions.
All watcherinfo subscribers and notifiers MUST support the
application/watcherinfo+xml format described in [3], and MUST list
its MIME type, application/watcherinfo+xml, in any Accept header
field present in the SUBSCRIBE request.
Other watcher information formats might be defined in the future. In
that case, the watcherinfo subscriptions MAY indicate support for
other formats. However, they MUST always support and list
application/watcherinfo+xml as an allowed format.
Of course, the watcherinfo notifications generated by the server MUST
be in one of the formats specified in the Accept header field in the
SUBSCRIBE request. If no Accept header field was present, the
notifications MUST use the application/watcherinfo+xml format
described in [3].
4.6 Notifier Processing of SUBSCRIBE Requests
RFC 3265 [1] specifies that packages should define any package-
specific processing of SUBSCRIBE requests at a notifier, specifically
J. Rosenberg [Page 7]
Internet Draft Watcher Information January 31, 2003
with regards to authentication and authorization.
The watcher information for a particular package contains sensitive
information. Therefore, all watcherinfo subscriptions SHOULD be
authenticated and then authorized before approval. Authentication MAY
be performed using any of the techniques available through SIP,
including digest, S/MIME, TLS or other transport specific mechanisms
[4]. Authorization policy is at the discretion of the administrator,
as always. However, a few recommendations can be made.
It is RECOMMENDED that user A be allowed to subscribe to their own
watcher information for any package. This is true recursively, so
that it is RECOMMENDED that a user be able to subscribe to the
watcher information for their watcher information for any package.
It is RECOMMENDED that watcherinfo subscriptions for some package foo
for user A be allowed from some other user B, if B is an authorized
subscriber to A within the package foo. However, it is RECOMMENDED
that the watcherinfo notifications sent to B only contain the state
of B's own subscription. In other words, it is RECOMMENDED that a
user be allowed to monitor the state of their own subscription.
To avoid infinite recursion of authorization policy, it is
RECOMMENDED that only user A be allowed to subscribe to
foo.winfo.winfo for user A, for any foo. It is also RECOMMENDED that
by default, a server does not authorize any subscriptions to
foo.winfo.winfo.winfo or any other deeper recursions.
4.7 Notifier Generation of NOTIFY Requests
The SIP Event framework requests that packages specify the conditions
under which notifications are sent for that package, and how such
notifications are constructed.
Watcherinfo notifications MAY be generated for watcher information on
package foo, when the subscription state for a user on package foo
changes. The watcher information package therefore needs a model of
subscription state. This is accomplished by specifying a subscription
Fine State Machine (FSM), described below, which governs the
subscription state of a user in any package. Watcherinfo
notifications MAY be generated on transitions in this state machine.
Its important to note that this FSM is just a model of the
subscription state machinery maintained by a server. An
implementation would map its own state machines to this one in an
implementation-specific manner.
4.7.1 The Subscription State Machine
J. Rosenberg [Page 8]
Internet Draft Watcher Information January 31, 2003
The underlying state machine for a subscription is shown in Figure 1.
It derives almost entirely from the descriptions in RFC 3265 [1], but
adds the notion of a waiting state.
Initially, there is no state allocated for a subscription (the init
state). When a SUBSCRIBE request arrives, the subscription FSM is
created. The next state depends on whether policy exists for the
subscription. If there is an existing policy that determines that the
subscription is forbidden, it moves into the terminated state
immediately, where the FSM can be destroyed. If there is existing
policy that determines that the subscription is authorized, the FSM
moves into the active state. This state indicates that the subscriber
will receive notifications.
If, when a subscription arrives, there is no authorization policy in
existence, the subscription moves into the pending state. In this
state, the server is awaiting an authorization decision. No
notifications are generated on changes in presence state (an initial
NOTIFY will have been delivered as per RFC 3265 [1]), but the
subscription FSM is maintained. If the authorization decision comes
back positive, the subscription is approved, and moves into the
active state. If the authorization is negative, the subscription is
rejected, and the FSM goes into the terminated state. It is possible
that the authorization decision can take a very long time. In fact,
no authorization decision may arrive until after the subscription
itself expires. If a pending subscription suffers a timeout, it moves
into the waiting state. At any time, the server can decide to end a
pending or waiting subscription because it is concerned about
allocating memory and CPU resources to unauthorized subscription
state. If this happens, a "giveup" event is generated by the server,
moving the subscription to terminated.
The waiting state is similar to pending, in that no notifications are
generated. However, if the subscription is approved or denied, the
FSM is destroyed. The purpose of the waiting state is so that a user
can fetch watcherinfo state at any time, and learn of any
subscriptions that arrived previously (and which may arrive again)
which require an authorization decision. Consider an example. A
subscribes to B. B has not defined policy about this subscription, so
it moves into the pending state. B is not "online", so that B's
software agent cannot be contacted to approve the subscription. The
subscription expires. Let's say it were destroyed. B logs in, and
fetches its watcherinfo state. There is no record of the subscription
from A, so no policy decision is made about subscriptions from A. B
logs off. A refreshes its subscription. Once more, the subscription
is pending since no policy is defined for it. This process could
continue indefinitely. The waiting state ensures that B can find out
J. Rosenberg [Page 9]
Internet Draft Watcher Information January 31, 2003
subscribe,
policy= +----------+
reject | |<------------------------+
+------------>|terminated|<---------+ |
| | | | |
| | | |noresource |
| +----------+ |rejected |
| ^noresource |deactivated |
| |rejected |probation |
| |deactivated |timeout |noresource
| |probation | |rejected
| |giveup | |giveup
| | | |approved
+-------+ +-------+ +-------+ |
| |subscribe| |approved| | |
| init |-------->|pending|------->|active | |
| |no policy| | | | |
| | | | | | |
+-------+ +-------+ +-------+ |
| | ^ ^ |
| subscribe, | | | |
+-----------------------------------+ |
policy = accept | | +-------+ |
| |subscribe | | |
| +----------|waiting|----------+
+----------->| |
timeout | |
+-------+
Figure 1: Subscription State Machine
about this subscription attempt.
The waiting state is also needed to allow for authorization of fetch
attempts, which are subscriptions that expire immediately.
Of course, policy may never be specified for the subscription. As a
result, the server can generate a giveup event to move the waiting
subscription to the terminated state. The amount of time to wait
before issuing a giveup event is system dependent. If, while in the
J. Rosenberg [Page 10]
Internet Draft Watcher Information January 31, 2003
waiting state, the subscription is refreshed through another
SUBSCRIBE, it moves back into the pending state.
The giveup event is generated in either the waiting or pending states
to destroy resources associated with unauthorized subscriptions.
Servers need to exercise care in selecting this value. It needs to be
large in order to provide a useful user experience; a user should be
able to log in days later and see that someone tried to subscribe to
them. However, allocating state to unauthorized subscriptions can be
used as a source of DoS attacks. Therefore, it is RECOMMENDED that
servers which retain state for unauthorized subscriptions add
policies which prohibit a particular subscriber from having more than
some number of pending or waiting subscriptions.
At any time, the server can deactivate a subscription. Deactivation
implies that the subscription is discarded without a change in
authorization policy. This may be done in order to trigger refreshes
of subscriptions for a graceful shutdown or subscription migration
operation. A related event is probation, where a subscription is
terminated, and the subscriber is requested to wait some amount of
time before trying again. The meaning of these events is described in
more detail in Section 3.2.4 of RFC 3265 [1].
A subscription can be terminated at any time because the resource
associated with that subscription no longer exists. This corresponds
to the noresource event.
4.7.2 Applying the State Machine
The server MAY generate a notification to watcherinfo subscribers on
a transition of the state machine. Whether it does or not is policy
dependent. However, several guidelines are defined.
Consider some event package foo. A subscribes to B for events within
that package. A also subscribes to foo.winfo for B. In this scenario
(where the subscriber to foo.winfo is also a subscriber to foo for
the same resource), it is RECOMMENDED that A receive watcherinfo
notifications only about the changes in its own subscription.
Normally, A will receive notifications about changes in its
subscription to foo through the Subscription-State header field. This
will frequently obviate the need for a separate subscription to
foo.winfo. However, if such a subscription is performed by A, the
foo.winfo notifications SHOULD NOT report any state changes which
would not be reported (because of authorization policy) in the
Subscription-State header field in notifications on foo.
As a general rule, when a watcherinfo subscriber is authorized to
receive watcherinfo notifications about more than one watcher, it is
J. Rosenberg [Page 11]
Internet Draft Watcher Information January 31, 2003
RECOMMENDED that watcherinfo notifications contain information about
those watchers which have changed state (and thus triggered a
notification), instead of delivering the current state of every
watcher in every watcherinfo notification. However, watcherinfo
notifications triggered as a result of a fetch operation (a SUBSCRIBE
with Expires of 0) SHOULD result in the full state of all watchers
(of course, only those watchers that have been authorized to be
divulged to the watcherinfo subscriber) to be present in the NOTIFY.
4.8 Subscriber Processing of NOTIFY Requests
RFC 3265 [1] expects packages to specify how a subscriber processes
NOTIFY requests in any package specific ways, and in particular, how
it uses the NOTIFY requests to contruct a coherent view of the state
of the subscribed resource. Typically, the watcherinfo NOTIFY will
only contain information about those watchers whose state has
changed. To construct a coherent view of the total state of all
watchers, a watcherinfo subscriber will need to combine NOTIFYs
received over time. This details of this process depend on the
document format. See [3] for details on the
application/watcherinfo+xml format.
4.9 Handling of Forked Requests
The SIP Events framework mandates that packages indicate whether or
not forked SUBSCRIBE requests can install multiple subscriptions.
When a user wishes to obtain watcher information for some resource
for package foo, the SUBSCRIBE to the watcher information will need
to reach a collection of servers that have, unioned together,
complete information about all watchers on that resource for package
foo. If there are a multiplicity of servers handling subscriptions
for that resource for package foo (for load balancing reasons,
typically), it is very likely that no single server will have the
complete set of watcher information. There are several solutions in
this case. This specification does not mandate a particular one, nor
does it rule out others. It merely ensures that a broad range of
solutions can be built.
One solution is to use forking. The system can be designed so that a
SUBSCRIBE for watcher information arrives at a special proxy which is
aware of the requirements for watcher information. This proxy would
fork the SUBCRIBE request to all of the servers which could possibly
maintain subscriptions for that resource for that package. Each of
these servers, whether or not they have any current subscribers for
that resource, would accept the watcherinfo subscription. Each needs
to accept because they may all eventually receive a subscription for
that resource. The watcherinfo subscriber would receive some number
J. Rosenberg [Page 12]
Internet Draft Watcher Information January 31, 2003
of watcherinfo NOTIFY requests, each of which establishes a separate
dialog. By aggregating the information across each dialog, the
watcherinfo subscriber can compute full watcherinfo state. In many
cases, a particular dialog might never generate any watcherinfo
notifications; this would happen if the servers never receive any
subscriptions for the resource.
In order for such a system to be built in an interoperable fashion,
all watcherinfo subscribers MUST be prepared to install multiple
subscriptions as a result of a multiplicity of NOTIFY messages in
response to a single SUSCRIBE.
Another approach for handling the server multiplicity problem is to
use state agents. See Section 4.11 for details.
4.10 Rate of Notifications
RFC 3265 [1] mandates that packages define a maximum rate of
notifications for their package.
For reasons of congestion control, it is important that the rate of
notifications not become excessive. As a result, it is RECOMMENDED
that the server not generate watcherinfo notifications for a single
watcherinfo subscriber at a rate faster than once every 5 seconds.
4.11 State Agents
RFC 3265 [1] asks packages to consider the role of state agents in
their design.
State agents play an important role in this package. As discussed in
Section 4.9, there may be a multiplicity of servers sharing the load
of subscriptions for a particular package. A watcherinfo subscription
might require subscription state spread across all of those servers.
To handle that, a farm of state agents can be used. Each of these
state agents would know the entire watcherinfo state for some set of
resources. The means by which the state agents would determine the
full watcherinfo state is outside the scope of this specification.
When a watcherinfo subscription is received, it would be routed to a
state agent that has the full watcherinfo state for the requested
resource. This server would accept the watcherinfo subscription
(assuming it was authorized, of course), and generate watcherinfo
notifications as the watcherinfo state changed. The watcherinfo
subscriber would only have a single dialog in this case.
5 Example Usage
The following section discusses an example application and call flows
J. Rosenberg [Page 13]
Internet Draft Watcher Information January 31, 2003
using the watcherinfo package.
In this example, a user Joe, sip:joe@example.com provides presence
through the example.com presence server. Joe subscribes to his own
watcher information, in order to learn about people who subscribe to
his presence, so that he can approve or reject their subscriptions.
Joe sends the following SUBSCRIBE request:
SUBSCRIBE sip:joe@example.com SIP/2.0
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7
From: sip:joe@example.com;tag=123aa9
To: sip:joe@example.com
Call-ID: 9987@pc34.example.com
CSeq: 9887 SUBSCRIBE
Contact: sip:joe@pc34.example.com
Event: presence.winfo
Max-Forwards: 70
The server responds with a 401 to authenticate, and Joe resubmits the
SUBSCRIBE with credentials (message not shown). The server then
authorizes the subscription, since it allows Joe to subscribe to his
own watcher information for presence. It responds with a 200 OK:
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8
;received=192.0.2.8
From: sip:joe@example.com;tag=123aa9
To: sip:joe@example.com;tag=xyzygg
Call-ID: 9987@pc34.example.com
CSeq: 9988 SUBSCRIBE
Contact: sip:server19.example.com
Expires: 3600
Event: presence.winfo
The server then sends a NOTIFY with the current state of
presence.winfo for joe@example.com:
NOTIFY sip:joe@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
J. Rosenberg [Page 14]
Internet Draft Watcher Information January 31, 2003
Call-ID: 9987@pc34.example.com
CSeq: 1288 NOTIFY
Contact: sip:server19.example.com
Event: presence.winfo
Max-Forwards: 70
Content-Type: application/watcherinfo+xml
Content-Length: ...
sip:A@example.com
Joe then responds with a 200 OK to the NOTIFY:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii
;received=192.0.2.7
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1288 NOTIFY
The NOTIFY tells Joe that user A currently has a pending
subscription. Joe then authorizes A's subscription through some
means. This causes a change in the status of the subscription (which
moves from pending to active), and the delivery of another
notification:
NOTIFY sip:joe@pc34.example.com SIP/2.0
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1289 NOTIFY
Contact: sip:server19.example.com
Event: presence.winfo
Max-Forwards: 70
J. Rosenberg [Page 15]
Internet Draft Watcher Information January 31, 2003
Content-Type: application/watcherinfo+xml
Content-Length: ...
sip:A@example.com
B then responds with a 200 OK to the NOTIFY:
SIP/2.0 200 OK
Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij
;received=192.0.2.7
From: sip:joe@example.com;tag=xyzygg
To: sip:joe@example.com;tag=123aa9
Call-ID: 9987@pc34.example.com
CSeq: 1289 NOTIFY
6 Security Considerations
6.1 Denial of Service Attacks
Watcher information generates notifications about changes in the
state of watchers for a particular resource. It is possible for a
single resource to have many watchers, resulting in the possibility
of a large volume of notifications. This makes watcherinfo
subscription a potential tool for denial of service attacks.
Preventing these can be done through a combination of sensible
authorization policies and good operating principles.
Firstly, when a resource has a lot of watchers, watcherinfo
subscriptions to that resource should only be allowed from explicitly
authorized entities, whose identity has been properly authenticated.
That prevents a watcherinfo NOTIFY stream from being generated from
subscriptions made by an attacker.
Even when watcherinfo subscriptions are properly authenticated, there
are still potential attacks. For example, consider a valid user, T,
J. Rosenberg [Page 16]
Internet Draft Watcher Information January 31, 2003
who is to be the target of an attack. T has subscribed to their own
watcher information. The attacker generates a large number of
subscriptions (not watcherinfo subscriptions). If the server creates
subscription state for unauthenticated subscriptions, and reports
those changes in watcherinfo notifications, user T would receive a
flood of watcherinfo notifications. In fact, if the server generates
a watcherinfo notification when the subscription is created, and
another when it is terminated, there will be an amplification by a
factor of two. The amplification would actually be substantial if the
server generates full state in each watcherinfo notification. Indeed,
the amount of data sent to T would be the square of the data
generated by the attacker! Each of the N subscriptions generated by
the attacker would result in a watcherinfo NOTIFY being sent to T,
each of which would report on up to N watchers. To avoid this,
servers should never generate subscription state for unauthenticated
SUBSCRIBE requests, and should never generate watcherinfo
notifications for them either.
6.2 Divulging Sensitive Information
Watcher information indicates what users are interested in a
particular resource. Depending on the package and the resource, this
can be very sensitive information. For example, in the case of
presence, the watcher information for some user represents the
friends, family, and business relations of that person. This
information can be used for a variety of malicious purposes.
One way in which this information can be revealed is eavesdropping.
An attacker can observe watcherinfo notifications, and learn this
information. To prevent that, watchers MAY use the SIPS scheme when
subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST
support TLS and SIPS as if they were a proxy (see Section 26.3.1 of
RFC 3261).
SIP encryption, using S/MIME, MAY be used end-to-end for the
transmission of both SUBSCRIBE and NOTIFY requests.
Another way in which this information can be revealed is through
spoofed subscriptions. These attacks can be prevented by
authenticating and authorizing all watcherinfo subscriptions. In
order for the notifier to authenticate the subscriber, it MAY use
HTTP Digest (Section 22 of RFC 3261). As a result, all watchers MUST
support HTTP Digest. This is a redundant requirement, however, since
all SIP user agents are mandated to support it by RFC 3261.
7 IANA Considerations
This specification registers an event template package as specified
J. Rosenberg [Page 17]
Internet Draft Watcher Information January 31, 2003
in Section 6.2 of RFC 3265 [1].
Package Name: winfo
Template Package: yes
Published Specification: RFC XXXX (Note to IANA: Please replace
XXXX with the RFC number of this specification.)
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
8 Acknowledgements
The authors would like to thank Adam Roach, Allison Mankin and Brian
Stucker for their detailed comments.
9 Authors Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
10 Normative References
[1] A. B. Roach, "Session initiation protocol (sip)-specific event
notification," RFC 3265, Internet Engineering Task Force, June 2002.
[2] S. Bradner, "Key words for use in rfcs to indicate requirement
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997.
[3] J. Rosenberg, "An extensible markup language (XML) based format
for watcher information," internet draft, Internet Engineering Task
Force, Dec. 2002. Work in progress.
[4] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J.
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session
initiation protocol," RFC 3261, Internet Engineering Task Force, June
2002.
11 Informative References
[5] J. Rosenberg, "A presence event package for the session
J. Rosenberg [Page 18]
Internet Draft Watcher Information January 31, 2003
initiation protocol (SIP)," internet draft, Internet Engineering Task
Force, Dec. 2002. Work in progress.
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.
Full Copyright Statement
Copyright (c) The Internet Society (2003). 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.
J. Rosenberg [Page 19]
Internet Draft Watcher Information January 31, 2003
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.
J. Rosenberg [Page 20]