Figure 1: Subscription State Machine
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.
The giveup event is generated in either the waiting or pending states
to destroy resources associated with unauthorized subscriptions.
This event is generated when a giveup timer fires. This timer is set
to a timeout value when entering either the pending or waiting
states. 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 that 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
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.
Frequently, states in the subscription state machine will be
transient. For example, if an authorized watcher performs a fetch
operation, this will cause the state machine to be created,
transition from init to active, and then from active to terminated,
followed by a destruction of the FSM. In such cases, watcherinfo
notifications SHOULD NOT be sent for any transient states. In the
prior example, the server wouldn’t send any notifications, since all
of the states are transient.
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 construct 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 SUBSCRIBE 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
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 SUBSCRIBE.
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
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
Call-ID: 9987@pc34.example.com
CSeq: 1288 NOTIFY
Contact: sip:server19.example.com
Event: presence.winfo
Subscription-State: active
Max-Forwards: 70
Content-Type: application/watcherinfo+xml
Content-Length: ...
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:joe@example.com" package="presence">
<watcher id="77ajsyy76" event="subscribe"
status="pending">sip:A@example.com</watcher>
</watcher-list>
</watcherinfo>
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
Subscription-State: active
Max-Forwards: 70
Content-Type: application/watcherinfo+xml
Content-Length: ...
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="1" state="partial">
<watcher-list resource="sip:joe@example.com" package="presence">
<watcher id="77ajsyy76" event="approved"
status="active">sip:A@example.com</watcher>
</watcher-list>
</watcherinfo>
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.
First, 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,
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 URI 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
in Section 6.2 of RFC 3265 [1].
Package Name: winfo
Template Package: yes
Published Specification: RFC 3857
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. Normative References
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J., "An Extensible Markup Language (XML) Based Format
for Watcher Information", RFC 3858, August 2004.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
10. Informative References
[5] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, July 2004.
11. Author’s Address
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
EMail: jdrosen@dynamicsoft.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.