SIMPLE WG O. Levin
Internet-Draft Microsoft Corporation
Expires: January 20, 2006 A. Houri
IBM
E. Aoki
America Online, Inc.
T. Rang
Microsoft Corporation
July 19, 2005
Inter-domain Requirements for SIP/SIMPLE
draft-levin-simple-interdomain-reqs-03
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 January 20, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document identifies a SIP/SIMPLE profile for inter-domain
communications and documents best current practices regarding
security and "good citizenship" behavior that operators should use
Levin, et al. Expires January 20, 2006 [Page 1]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
when interconnecting two or more clouds using SIP/SIMPLE. The
purpose of this document is to serve as the reference for the SIP/
SIMPLE community towards inter-domain interoperability and also to
identify new requirements specific to the inter-domain interface.
Table of Contents
1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Topology and Architecture . . . . . . . . . . . . . . . . . . 3
4. Connecting SIP/SIMPLE Communities . . . . . . . . . . . . . . 5
4.1 Configuration and Discovery . . . . . . . . . . . . . . . 5
4.2 Connection Management . . . . . . . . . . . . . . . . . . 5
4.3 Transport Security . . . . . . . . . . . . . . . . . . . . 6
4.4 Compression . . . . . . . . . . . . . . . . . . . . . . . 6
5. Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1 SIP/SIMPLE Profile for Presence . . . . . . . . . . . . . 7
5.2 Presence Format . . . . . . . . . . . . . . . . . . . . . 8
5.3 Automatic Periodic Presence Operations . . . . . . . . . . 9
5.3.1 Reasserting Subscriptions . . . . . . . . . . . . . . 9
5.3.2 Reasserting Presence . . . . . . . . . . . . . . . . . 9
6. Instant Messaging (IM) . . . . . . . . . . . . . . . . . . . . 10
6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Page IM . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3 Session IM . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3.1 MSRP . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3.2 MESSAGE inside INVITE Session . . . . . . . . . . . . 11
7. SIP Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 13
8. Agreements . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9. Requirements for Standard Extensions . . . . . . . . . . . . . 13
9.1 Recording and Logging . . . . . . . . . . . . . . . . . . 13
9.2 Inter-community User Trust Level . . . . . . . . . . . . . 14
9.3 Add/Remove Contact . . . . . . . . . . . . . . . . . . . . 14
9.4 Configuration . . . . . . . . . . . . . . . . . . . . . . 15
10. Security Considerations . . . . . . . . . . . . . . . . . . 15
10.1 Implicit Authority . . . . . . . . . . . . . . . . . . . . 16
10.2 Spam Prevention . . . . . . . . . . . . . . . . . . . . . 16
10.3 Federated Contacts Accuracy . . . . . . . . . . . . . . . 17
10.4 Address Confidentiality and Validity . . . . . . . . . . . 17
10.5 Policy Discovery . . . . . . . . . . . . . . . . . . . . . 18
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 18
13. Change History . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1 Normative References . . . . . . . . . . . . . . . . . . . 19
14.2 Informational References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22
Levin, et al. Expires January 20, 2006 [Page 2]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
1. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [1].
2. Introduction
With increased adoption of SIP and SIMPLE based presence and instant
messaging systems, it becomes more important to specify a uniform
profile these systems will use to exchange presence information and
instant messages (IMs) and to document best current practices
regarding security and "good citizenship" behavior that operators
should use when interconnecting SIP/SIMPLE clouds.
The purpose of this document is not to become a normative profile but
rather to serve as the reference for the SIP/SIMPLE deployers
community towards inter-domain interoperability and also to identify
new requirements specific to the inter-domain interface.
The document is structured into the following main sections:
o Topology and Architecture (Section 3)
o Connecting Communities via SIP/SIMPLE (Section 4)
o Presence (Section 5)
o Instant Messaging (Section 6)
o SIP Miscellaneous (Section 7)
o Requirements for Standard Extensions (Section 9)
o Security Considerations (Section 10)
3. Topology and Architecture
For the purposes of this document, we consider users as "belonging"
to a given SIP/SIMPLE presence and messaging community. A SIP/SIMPLE
community administers its own namespace of SIP addresses or has other
administrative authority over a collection of users and/or SIP/SIMPLE
endpoints. The users of an enterprise, the subscribers of a mobile
operator, or the customers of a given service provider are examples
of such communities.
It is certainly true that an individual in one community (as
represented by a presentity and/or instant inbox in a given domain)
can communicate (perhaps through a series of proxies) to another
individual in another community (i.e., a corresponding presentity/
instant inbox in a different domain) without the need for an
interdomain profile. However, in many real-world cases, domains
represent a unit of administrative control that impose additional
requirements around authorization, confidentiality, and the like.
The interdomain profile can also be useful where the edge proxy is a
Levin, et al. Expires January 20, 2006 [Page 3]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
translating gateway and terminates inbound SIP/SIMPLE dialogs on
behalf of another system.
A typical deployment topology illustrating how two SIP/SIMPLE
communities might interconnect is shown in the figure below.
/\ /\
/U-A /U-B
/____\ ----------- /____\
///// \\\\\
_____ +-------+ // \\ +-------+ _____
/ / | | | | | | / /
/R-A / | EP-A | | Internet | | EP-B | /R-B /
/____/ | | | | | | /____/
+-------+ \\ // +-------+
_____ \\\\\ ///// _____
/ / ----------- / /
/P-A / /P-B /
/____/ /____/
The edge proxies (EP-A and EP-B) for a given community are SIP
proxies that have both ability and authority to route traffic from
the public network to the SIP entities within that community. Each
edge proxy is said to "service", "be responsible for", "act on behalf
of", or be "in" a community, which is to say that the edge proxy
listens for requests intended for a given community (identified by
its domain), routes the SIP traffic "to" and "from" the community,
and in some cases provides answers on behalf of the users and
entities within that community.
The other components shown in the picture are logical SIP/SIMPLE
entities internal to each community that participate in different
aspects of presence and IM. They include UAs/PUAs (U-A and U-B),
Registrars (R-A and R-B), and Presence Servers (P-A and P-B).
This document is concerned with the protocols and deployment
considerations of the "inter-domain interface" between two separately
administered SIP clouds. Put another way, the inter-domain interface
is the path between EP-A and EP-B, where traffic can traverse any
communication transport layer pertaining SIP/SIMPLE (e.g. VPN for
trusted domains). This path may optionally include a chain of SIP
proxies for application routing in-between.
Levin, et al. Expires January 20, 2006 [Page 4]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
4. Connecting SIP/SIMPLE Communities
4.1 Configuration and Discovery
When a user in a given SIP/SIMPLE community wishes to communicate
with users in a different community, a route must exist between the
sender's edge proxy (EP-A) and that of the destination (EP-B). To
establish this route, an edge proxy needs to learn the Fully
Qualified Domain Name (FQDN) of its peer proxy by means out-of-band
to SIP.
One means of discovery is the use DNS SRV records according to the
procedures in RFC-3263 [9]. However, some communities may wish to
implement more restrictive policy concerning other communities to
whom their users may communicate. These communities may choose not
to publish DNS SRV records or to be reached on unpublished ports, or
they may choose not to trust DNS for outbound connections.
Accordingly, it is RECOMMENDED that local edge proxies have the
ability to be statically provisioned with the list of valid DNS
domains to which they may connect. These are the DNS domains that
the remote edge proxy has the authority and the ability to route to.
Regardless of whether it is possible to discover the receiving edge
proxy for a given domain, the destination community may have specific
policies that govern who can connect to it. The specification of
these policies and rules surrounding their provisioning are out of
scope of this document.
4.2 Connection Management
Connections between presence and messaging communities SHOULD use
reliable and congestion safe connection for transport. These
connections are bi-directional, semi-persistent, and are established
on-demand by either edge proxy.
For large communities many thousands or millions of dialogs may be
occurring concurrently. Consequently, it would likely not be
appropriate for a community to establish one connection per SIP
dialog.
Data for multiple SIP dialogs can and will likely flow across a given
connection. Conversely, the requests and responses that make up a
given dialog may flow over any active connection that exists between
the two SIP/SIMPLE communities and is not guaranteed to flow over the
same connection as preceding requests. If a connection fails or
closed by either side due to a locally defined inactivity period or
policy, each side can initiate new connections at any time.
Levin, et al. Expires January 20, 2006 [Page 5]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
Although SIP/SIMPLE communities may establish more than one
connection to communicate with other, in consideration of
scalability, implementers are RECOMMENDED to limit the number of such
connections to a reasonable number. In any event, the receiving
community's edge proxy MAY refuse to accept more than a given number
of connections from a given edge proxy or from all of the edge
proxies that reside within a given community.
4.3 Transport Security
In order to prevent spoofing, provide better control against spam,
and allow privacy and secured transport, communities SHOULD require
the use of a secured transport layer. This could be achieved by
using IPSec or mutually authenticated TLS connection between the edge
proxies. Any requirement for secure connectivity SHOULD be agreed to
in advance by a bilateral offline agreement. If both edge proxies
are in a joint secure area, they MAY connect over an insecure
transport protocol.
According to the TLS protocol RFC-2246 [2], for establishment of the
mutually authenticated TLS connection, each server needs to present a
valid certificate to the other server. Each server also needs to
trust the certificate authority that issued the certificate presented
by the other proxy or trust the certificate itself. Once a TLS
connection is established between two edge proxies, it is trusted for
the life of the connection as long as the certificate is valid. When
using a secure transport, the edge proxy of both side act as the
security UA, leaving the internal components from dealing with the
transport security.
As indicated in the preceding section, between two edge proxies, one
or more connections can be simultaneously maintained. If a group of
TLS connections is maintained between the two edge proxies, the same
certificate MUST be used for all connections servicing a given
community. This allows allocation of SIP dialogs among the TLS
connections according to local policy and without requiring
additional protocols between the communities.
4.4 Compression
SIP/SIMPLE is a relatively verbose protocol, and for very large
communities, a significant amount of traffic will need to travel
across the interdomain boundary to transmit presence and messaging
information. In order to reduce the amount of data that passes
between two communities, edge proxies may employ compression. Data
compression is particularly effective because much of the data,
including SIP header names or addressee domain names, are repeated in
each SIP message.
Levin, et al. Expires January 20, 2006 [Page 6]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
Edge proxies may implement data compression using any mutually agreed
compression mechanism. RFC-3485 [12] specifies an application-level
compression mechanism, SigComp, which uses a predefined data
dictionary to reduce the overhead of repetitive SIP messages. RFC-
3486 [13] describe how to signal the use of SigComp or an alternate
application compression mechanism within the SIP data flow.
Alternately, implementations may choose to use transport level
compression. However, the need to support TLS encryption (above) may
have an impact on the selection of compression algorithms. For this
reason, edge proxies supporting transport compression SHOULD
minimally support the mechanism of negotiating TLS protocol
compression, as specified in RFC-2246 [2], and one or more TLS
compression methods (other than the null compression method). At the
time of this writing, RFC-3749 [10] and RFC-3943 [11] are examples of
transport-level compression methods.
5. Presence
5.1 SIP/SIMPLE Profile for Presence
In order to get the presence information from a user in a different
community, the standard SIP SUBSCRIBE/NOTIFY mechanisms defined in
RFC-3265 [5] and RFC-3856 [7] are used.
An edge proxy may receive SUBSCRIBE requests for presentities that do
not exist within its community or are restricted by local policy from
communicating across communities. For example, a mistyped contact
name or the removal of a previously valid identity (e.g. enterprise
user quits the company) could result in this case.
In the interdomain case, the receiving edge proxy typically answers
on behalf of entities within the community it represents, so in
accordance with RFC-3265 [5], it SHOULD reject the session by issuing
one of the 4XX responses (e.g. "404 Not found" or "403 Forbidden") to
SUBSCRIBE. If one of the 4XX responses is generated, it is strongly
RECOMMENDED that the originating community does not automatically
(i.e. without user intervention) retry the same SUBSCRIBE request
again.
Alternately, the receiving edge proxy MAY accept the SUBSCRIBE using
a 2xx response and indicate in a subsequent NOTIFY that the
presentity is not available (i.e. has "closed" status). A given
community may wish to do this to maintain a greater level of
confidentiality, as described in section 5.2 of RFC-3265 [5]; for
example, in order to prevent dictionary attacks to harvest valid
presentity addresses.
Levin, et al. Expires January 20, 2006 [Page 7]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
In some cases, the receiving edge proxy may want to indicate that the
principal specified in the Request URI is one for which presence does
not apply. For example, a SIP URI specified as the recipient of a
subscription may correspond to a distribution list or other address
that is explicitly known to have no presence data, regardless of the
watcher. In this case, the edge proxy responsible for a given
community MAY return 604 ("Does Not Exist Anywhere") in response to
the SUBSCRIBE request. The edge proxy representing the requester's
community MAY, upon receiving a 604 response, safely store local
state that can be used to short circuit future similar SUBSCRIBE
requests to that presentity from any watcher. The watcher's proxy
may treat any similar subsequent SUBSCRIBE requests that the it would
normally send to the presentity as having returned a 404 response
code and MAY cache the 604 response for a relatively long-lived
period of time not to exceed 30 days. Note that because the
originating edge proxy essentially turns the 604 response into a 404
response, this optimization has the same confidentiality concerns as
returning 404 would. On the other hand, the purpose of the 604
response is to explicitly indicate that subsequent requests will fail
for all watchers, so there should be no expectation of
confidentiality in this case.
5.2 Presence Format
The basic presence format used between users in different communities
is defined by Presence Information Data Format [8]. This standard
format is signaled by including the "Accept" header with
"application/pidf+xml" in the SUBSCRIBE as (at least) one of the
possible presence formats the watcher understands.
Any additional presence information MAY be exchanged over the inter-
domain interface if encoded according to standard XML extension
techniques. It is expected that the following additional standard
user information is especially useful to be conveyed between SIP/
SIMPLE communities:
o "activity" element defined in Rich Presence Extensions [16].
o "icon" element defined in Contact Information [17].
o "display-name" element defined in Contact Information [17].
A PUA MUST be capable of receiving any XML extended schema, compliant
with the standard, and gracefully ignore any extensions it doesn't
understand.
An example of a valid presence document is shown below:
Levin, et al. Expires January 20, 2006 [Page 8]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
open
on-the-phone
sip:tom-pc@example.com
Tom Jones
5.3 Automatic Periodic Presence Operations
Some SIP/SIMPLE communities may reassert subscription requests or
presence notifications without user intervention in order to provide
a form of self-repair or to update stale data.
5.3.1 Reasserting Subscriptions
A watcher within a SIP/SIMPLE community MAY automatically
periodically generate re-SUBSCRIBEs towards a presentity within an
external SIP/SIMPLE community (for example, in order to ensure
contact accuracy). In order to prevent gratuitous re-SUBSCRIBES from
resulting in a large amount of traffic over the interdomain link, the
proxy representing the presentity SHOULD check the "Expires" header
and return a "423 Interval too small" with a "Min-Expires" header
field if the expiration interval specified for the subscription is
too short.
Similarly, absent any bilateral agreement between the administrative
authorities for each community, a watcher MUST NOT gratuitously
refresh the subscription more frequently than implied by the
expiration time of the subscription unless necessary to communicate
changes in subscription parameters, request a full state refresh
after synchronization has been lost with partial notification state,
or in response to explicit user activity.
5.3.2 Reasserting Presence
An entity within a SIP/SIMPLE community MAY automatically
Levin, et al. Expires January 20, 2006 [Page 9]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
periodically generate NOTIFYs towards an external SIP/SIMPLE
community. In the absence of any bilateral agreement between the
administrative authorities for each community, data refreshes within
the same SUBSCRIBE dialog MUST NOT occur more frequently than every
10 minutes. This limitation doesn't apply to notifications about
dynamic changes in users' state (for example, a user transitioning
from an "open" to "closed" state).
6. Instant Messaging (IM)
6.1 General
At the time of this writing, two major modes of IM are being used in
networks: Page mode and Session mode.
It is expected that the two modes will coexist in the future side-by-
side in the same network: each mode optimized for and being used by
different applications and potentially resulting in different user
experiences.
It is strongly RECOMMENDED that upon receiving a request to initiate
a specific IM mode, if the requested UA either doesn't support the
mode or is not willing to communicate by it, the UA responds with
"488 Not Acceptable Here" with Warning header field value explaining
why the offer was rejected and expressing the alternative IM mode by
including its capabilities as specified in section 11.1 and 21.4.26
of RFC-3261 [3] and as shown for each mode specifically in the
sections below.
Before establishing IM communications towards a remote UA, a UA MAY
query its peer's IM capabilities using the SIP OPTIONS request
specified in RFC-3261 [3].
6.2 Page IM
The Page mode IM is fully specified in RFC-3428 [6].
A UA that is willing to communicate using the page mode IM, responds
to the OPTIONS request by including the Allow header with listing the
MESSAGE as one of the methods it supports as shown in the example
below:
Levin, et al. Expires January 20, 2006 [Page 10]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877
;received=192.0.2.4
To: ;tag=93810874
From: Alice ;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 63104 OPTIONS
Contact:
Contact:
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, MESSAGE
Accept: application/sdp
Supported: foo
Content-Type: application/sdp
Content-Length: 274
(SDP not shown)
As described for presence, above, an edge proxy may receive MESSAGE
requests for IM addresses that do not exist within the community or
are restricted by local policy from communicating with other
communities. In these cases, the receiving community SHOULD return a
4XX response (e.g. "404 Not found" or "403 Forbidden") to MESSAGE.
If one of the 4XX responses is generated, it is strongly RECOMMENDED
that the originating UA refrains from issuing additional MESSAGE
requests within a reasonable timeframe. A receiving community MAY
alternately return a 2xx response and fail to deliver the message. A
given community may wish to do this in order to prevent dictionary
attacks to harvest valid IM addresses. If the address is not a valid
endpoint for instant messages regardless of sender, the receiving
edge proxy MAY return 604 Does Not Exist Anywhere. The sending edge
proxy may cache the 604 response and immediately return a 404
Forbidden to subsequent MESSAGE requests from any sender to the
specified address.
6.3 Session IM
6.3.1 MSRP
At the time of this writing, the Message Sessions Relay Protocol
(MSRP) [14] is under definition within the SIMPLE working group.
Once it is standardized, it will become a valid IM means over inter-
domain links.
6.3.2 MESSAGE inside INVITE Session
At the time of this writing, the only deployed session IM is the
MESSAGE SIP method being sent inside INVITE SIP dialog. This is one
Levin, et al. Expires January 20, 2006 [Page 11]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
of the possible behaviors described in Section 2 of RFC-3428 [6] and
the ideas from the draft-ietf-simple-im-sdp-00 "Extensions for SIP
Instant Message Sessions" by B. Campbell and J. Rosenberg from July
13th 2001. This mode has never been fully standardized.
Concerns about streaming data inside the signaling path have been
expressed in the past. Most objections were related to the SIP
ability running over UDP. As this document recommends the use of TLS
or TCP, "MESSAGE inside INVITE Session" mode can be used with proper
data flow control for potentially significant traffic inside the SIP
signaling path.
The SIP session is established according to SIP RFC-3261 [3] and SDP
"Offer-Answer Model" RFC-3264 [4] procedures.
In order to establish the IM session, a client issues SIP INVITE with
the SDP body containing (at least) the following m-line:
m=message 5060 sip/tcp *
The "SIP URI" SHOULD be the value from the Contact header and MAY be
omitted.
The consequent MESSAGE methods RFC-3428 [6] are constructed and sent
according to standard SIP rules for messages inside a SIP dialog as
defined in section 12.2 of RFC-3261 [3].
The recipient's UA MUST ignore any headers and parameters in the
MESSAGE that it doesn't understand.
The recipient's UA MUST ignore any attributes and parameters in the
SDP document that it doesn't understand.
The recipient UA MUST reject all m-lines in the SDP document that it
doesn't understand or doesn't support by using the standard SDP
convention (i.e. by setting the "port" parameter in the m-line to
"0").
A UA that is willing to communicate using the MESSAGE method inside
SIP session, includes an SDP document with
m=message 5060 sip/tcp *
when responding to OPTIONS and in "488 Not Acceptable Here" responses
in the SDP format defined in section 9 of "Offer-Answer Model" RFC-
3264 [4].
Levin, et al. Expires January 20, 2006 [Page 12]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
7. SIP Miscellaneous
SIP public proxies (i.e. those proxies through which a SIP message
transits between edge proxies of SIP/SIMPLE communities) SHOULD
preserve all SIP headers and parameters they don't understand.
If the accumulated length of Record Route headers in incoming (from
an inter-domain link) SIP request exceeds the local policy of the
receiving community, the recipient SHOULD reject the session by
responding with "513 Message Too Large" to the request.
8. Agreements
Before connecting separately administrated SIP/SIMPLE communities,
certain local procedures need to be implemented by each community in
order to become a good global SIP/SIMPLE citizen. Each community
also SHOULD take precautions in order to defend itself (both
reactively and proactively) from potentially badly behaving other
communities. This document describes a number of these best
practices.
However, many of these procedures are largely a matter of local
policy and in many cases can not be enforced by communication
protocols. Therefore, it is expected that many of the proposed
solutions will be referred to and enforced by bilateral business
agreements before enabling the inter-domain connection. These
agreements may specify policies regarding rate limits, which
communities can connect to one another, and other interdomain
concerns.
Communities that attempt to communicate with another community in the
absence of such an agreement MUST adhere to the provisions in this
document, particularly those referenced in the security
considerations section, below.
9. Requirements for Standard Extensions
In describing the best practices and conventions for communicating
between disparate SIP/SIMPLE communities, the authors have identified
several additional areas worthy of potential standardization. These
areas are listed here for discussion; as they become formalized, they
will be described in future versions of this document.
9.1 Recording and Logging
For each SIP session, during the establishment and renegotiation
phase it MUST be possible by standard means to inform the
participants that the session is going to be recorded or logged.
Levin, et al. Expires January 20, 2006 [Page 13]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
The recording or logging party, during the session establishment or
renegotiation, MUST have a standard means to inform the session
participants about the operation to take place.
9.2 Inter-community User Trust Level
Each community is responsible for verifying the identities of its
users. As verification can take different forms, we introduce the
concept of "user trust". While related to authentication, user trust
differs in that authentication provides assurance that a user with a
given identity has provided proper credentials to authenticate
himself into a system. User trust verifies that the user is
authorized to use the identity.
For example, in a system where participants can register using email
addresses - these addresses may be used as one form of identity
verification. The system may send an email message to the given
identifier and wait for an email response to verify that the
registrant is authorized to use the email account associated with
that address. In another case, a service provider may employ an
image test or obtain a credit card number to determine that a
registrant is a person and not a software "bot". Accreditation
systems may also play a role in establishing user trust.
Because of the wide range of verification assertions (including,
potentially the "null" assertion), and because it is possible that
users in the same community are being verified by different means and
are being consequently assigned a different trust level by their same
community, it is REQUIRED that a "user trust level" be defined and
standardized to convey this information to other trusted communities
across the inter-domain link. The scope of "user trust level"
terminology should cover presence exchange, call establishment, and
page IM communications.
Over the inter-domain link, it MUST be possible to convey per user
the level of the "user trust" as considered by its own community.
For communities that implement a single level trust policy across
their users, the edge proxies MAY provide this indication. If the
indication is not present, the federated users MAY be regarded as
"non-trusted" by other communities.
9.3 Add/Remove Contact
In the event a user is removed from its SIP/SIMPLE community, it MUST
be possible (though not required) for the community to communicate
this removal to the presentity's known watchers in external
communities using standard means.
Levin, et al. Expires January 20, 2006 [Page 14]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
Some communities require a watcher to obtain consent from a
presentity before establishing a presence subscription, or to obtain
consent from the recipient before a message can be sent. In order to
support these kinds of communities, it MUST be possible for users to
request these kinds of consent without actually establishing
communication (i.e., without establishing a presence subscription or
sending a message).
This consent request will allow the recipient to validate the
requesting user and consider adding him/her to the contact list
and/or accept communications and result in a better user experience
for interacting with initially non-trusted users.
9.4 Configuration
In order to enable seamless interaction between two communities, it
should be possible for a given community to automatically discover
another community's policies. An XML document that specifies various
configuration parameters of each community SHOULD be defined. The
schema will be exchanged or referenced between the communities upon
the creation of an initial connection and upon any update to it.
The schema will contain, for example the accepted subscription
duration, the allowed notify rate, administrator contact information,
and other parameters that will be identified as enabling a smoother
connection between the communities.
10. Security Considerations
This document describes a number of requirements and best practices
for interconnecting distinctly administered SIP/SIMPLE communities
for the purpose of exchanging presence and instant messages. Because
these inter-domain connections traverse the public Internet, it is
especially important to be conscious of security in order to preserve
user privacy and to take into account scalability and operational
requirements for the network.
In that vein, this entire document describes a number of practices
that directly or indirectly relate to security, but in particular,
Section 4.3 describes specific tactics meant to defend against
eavesdropping and man-in-the-middle attacks, and to provide for data
integrity and other protections. Other sections describe conventions
and techniques that can be used to mitigate the risk of DOS attacks
and to prevent undue traffic over the network.
It is important to note that this document primarily describes the
interactions that take place over the inter-domain interface.
Because these inter-domain connections exist between edge proxies and
Levin, et al. Expires January 20, 2006 [Page 15]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
not directly between end-user UAs, issues surrounding the
authentication of UAs internally or of securing intra-community
traffic are considered out of scope. Nonetheless, each community is
assumed to be responsible for its own internal security, and edge
proxies are explicitly assumed to be authoritative and responsible
for traffic originating within a community.
10.1 Implicit Authority
In the inter-domain model described here, a domain is assumed to have
the implicit authority to terminate requests and responses on behalf
of entities under its administrative control. In this model, all
interdomain communications originating from or terminating in a given
domain MUST pass through the edge proxy acting on behalf of that
domain. The edge proxy for a given community MAY reject connections
from entities purporting to be part of a given domain that do not
traverse that domain's edge proxy.
10.2 Spam Prevention
Given the prevalence of spam in other communications media, it
deserves special consideration. Spam is defined in this case as
unsolicited presence requests and instant messaging traffic and sent
from an inter-domain link to a recipient unwilling to process this
traffic.
The SIP and Spam [18] document discusses many techniques that can be
used to reduce spam with their advantages and disadvantages.
This document concentrates on technologies that are deployable today
and the techniques applicable to the multi-domain topology with SIP
edge proxies on the borders of each domain or community. Because
edge proxies (and the intermediate proxies, if deployed) are
interconnected using mutually authenticated TLS links, the
fundamental trust model for parties in the network can be reliably
maintained.
Each community is assumed to be responsible for taking measures to
prevent its own users from generating spam. Each community is also
responsible for preventing unauthorized access that would allow a
malicious third party to gain access to the network for the purpose
of sending spam. These techniques are considered out of scope of
this document.
Each community SHOULD have mechanisms in place to disable its own
users that are injecting spam into the inter-domain interface. Most
efficiently, this can be achieved by toughening the white list local
policies around federated users based on the user's perceived trust
Levin, et al. Expires January 20, 2006 [Page 16]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
level. The specifics of these local policies are out of scope of
this document.
A receiving community's edge proxy SHOULD take into account factors
such as the calling party's User Trust Level (section 9.2), the
number of instant messages received from a given sender or community
(either to a single recipient or aggregated across all users in a
community), or using any of the other techniques listed in [18]. The
receiving proxy MAY reject or close connections, provide degraded
service, or employ other local policy to deal with these attacks.
10.3 Federated Contacts Accuracy
An additional issue that occurs with inter-community presence is that
presence subscriptions are typically long-lived and are identified
only with a SIP "Address of Record" (AoR). If a principal leaves a
community and is subsequently replaced by another principal having
the same address as the departed principal, the new principal may
receive messages for, or be exposing presence to, entities that are
trying to communicate with the previous principal.
Therefore, for inter-community communications, it is REQUIRED that
the communities not reassign a removed user AoR to a new user for at
least 90 days after the old user was removed from the community.
In order to ensure the validity of a user's contact lists and ACLs,
it is strongly RECOMMENDED that the network services periodically re-
SUBSCRIBE to all external contacts in the lists at least every 45
days. The availability of the ability to convey Add/Remove contact
information (section 9.3) may also provide assistance in this regard.
10.4 Address Confidentiality and Validity
This document proposes a new usage of the 604 response code to
indicate that a request URI is not a valid presentity and/or instant
inbox for any watcher or sender. The use of this response code is
suggested as an optimization that allows a given domain to avoid
sending traffic over the inter-domain link that will very likely
result in a failure. While the use of the 604 response code is
optional, its use does warrant some additional security discussion.
The 604 response as described here is intended to be cached at the
sender and used to prevent subsequent requests to the same recipient
from being issued. It should therefore only be returned for extant,
valid addresses that are explicitly indicated not to have presence
and/or messaging capabilities, not for addresses that are simply
invalid or unassigned.
Levin, et al. Expires January 20, 2006 [Page 17]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
An attacker could use this knowledge to determine that a 604 response
for a given request means that the address specified in the request's
URI is valid and refers to some entity within the domain. Domains
that wish to maintain the confidentiality of valid addresses within
their domain should not use the 604 response code and should instead
return a 2xx code with a subsequent NOTIFY message containing
potentially correct data.
One other issue is that the 604 response may have a long-lived cache.
If an address for which a 604 had previously been returned suddenly
becomes a valid presentity and/or instant inbox, other domains would
not necessarily recognize this fact until their local cache of the
604 response had expired. In the worst case, this local cache may be
stale for up to 30 days.
10.5 Policy Discovery
The advertisement of various local policy attributes, such as contact
refresh times or administrator contact information raises the
possibility that an attacker will be able to use these means to
discover vulnerabilities in a target system. Additionally, if
contact information were included in such an advertisement, it is
possible that an attacker could harvest this information to send spam
or otherwise harass a domain administrator.
However, information that is expected to be conveyed in a policy
document is generally readily available by other means. Subscription
refresh values, for example are conveyed as part of the SUBSCRIBE
operation, and most large domains have well-known contact addresses
for administrators. Therefore, the creation of a policy document is
not expected to create any additional vulnerabilities.
11. IANA Considerations
None.
12. Acknowledgments
Thanks to Sharon Fridman, Followap for a review of the document and
helpful suggestions, and to the members of the SIMPLE working group
mailing list who provided additional comments and feedback.
13. Change History
-02 to -03: Incorporated comments from the mailing list
Included text regarding use of the 604 response
Added discussion of compression
Added additional discussion of security concerns
Added this Change History section
Levin, et al. Expires January 20, 2006 [Page 18]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
Miscellaneous typos and cleanup
14. References
14.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[3] 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.
[4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[7] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[8] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)",
RFC 3863, August 2004.
14.2 Informational References
[9] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[10] Hollenbeck, S., "Transport Layer Security Protocol Compression
Methods", RFC 3749, May 2004.
[11] Friend, R., "Transport Layer Security (TLS) Protocol
Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943,
November 2004.
[12] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.
Roach, "The Session Initiation Protocol (SIP) and Session
Description Protocol (SDP) Static Dictionary for Signaling
Levin, et al. Expires January 20, 2006 [Page 19]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
Compression (SigComp)", RFC 3485, February 2003.
[13] Camarillo, G., "Compressing the Session Initiation Protocol
(SIP)", RFC 3486, February 2003.
[14] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-10 (work in progress),
February 2005.
[15] Jennings, C., "Relay Extensions for the Message Sessions Relay
Protocol (MSRP)", draft-ietf-simple-msrp-relays-05 (work in
progress), July 2005.
[16] Schulzrinne, H., "RPID: Rich Presence Extensions to the
Presence Information Data Format", draft-ietf-simple-rpid-08
(work in progress), July 2005.
[17] Schulzrinne, H., "CIPID: Contact Information in Presence
Information Data Format", draft-ietf-simple-cipid-06 (work in
progress), July 2005.
[18] Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", draft-ietf-sipping-spam-00 (work in progress),
February 2005.
Authors' Addresses
Orit Levin
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: oritl@microsoft.com
Avshalom Houri
IBM
Science Park Building 18/D
Rehovot,
Israel
Email: avshalom@il.ibm.com
Levin, et al. Expires January 20, 2006 [Page 20]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
Edwin Aoki
America Online, Inc.
360 W. Caribbean Drive
Sunnyvale, CA 94089
USA
Email: aoki@aol.net
Tim Rang
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
Email: timrang@microsoft.com
Levin, et al. Expires January 20, 2006 [Page 21]
Internet-Draft Inter-domain Profile for SIP/SIMPLE July 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Levin, et al. Expires January 20, 2006 [Page 22]