< draft-tschofenig-sipping-spit-policy-00.txt   draft-tschofenig-sipping-spit-policy-01.txt >
Network Working Group H. Tschofenig SIPPING H. Tschofenig
Internet-Draft Siemens Networks GmbH & Co KG Internet-Draft Nokia Siemens Networks
Intended status: Standards Track D. Wing Intended status: Standards Track D. Wing
Expires: August 30, 2007 Cisco Expires: January 9, 2008 Cisco
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia University
T. Froment T. Froment
Alcatel-Lucent Alcatel-Lucent
G. Dawirs G. Dawirs
University of Namur University of Namur
February 26, 2007 July 8, 2007
Anti-SPIT : A Document Format for Expressing Anti-SPIT Authorization A Document Format for Expressing Authorization Policies to tackle Spam
Policies and Unwanted Communication for Internet Telephony
draft-tschofenig-sipping-spit-policy-00.txt draft-tschofenig-sipping-spit-policy-01.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 42 skipping to change at page 1, line 42
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2007. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
SPAM, defined as sending unsolicited messages to someone in bulk, SPAM, defined as sending unsolicited messages to someone in bulk,
might be a problem on SIP open-wide deployed networks. The might be a problem on SIP open-wide deployed networks. The
responsibility for filtering or blocking calls can belong to responsibility for filtering or blocking calls can belong to
skipping to change at page 3, line 12 skipping to change at page 3, line 12
by the SIP identity mechanism, by information carried within SAML by the SIP identity mechanism, by information carried within SAML
assertions. assertions.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Structure of SPIT Authorization Documents . . . . . . . . 5 3.1. Structure of SPIT Authorization Documents . . . . . . . . 5
3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5
4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 5 4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 6
4.1. MessagePattern Element . . . . . . . . . . . . . . . . . . 6 4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. MethodUsed Element . . . . . . . . . . . . . . . . . . . . 6 4.1.1. Acceptable Forms of Authentication . . . . . . . . . . 6
4.3. Assertions-Specific Parameters . . . . . . . . . . . . . . 6 4.1.2. Computing a URI for the Sender . . . . . . . . . . . . 7
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Handling Action . . . . . . . . . . . . . . . . . . . . . 7 4.3. SPIT Handling . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Redirect Action . . . . . . . . . . . . . . . . . . . . . 8 4.4. Media List . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. Method List . . . . . . . . . . . . . . . . . . . . . . . 10
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.6. MIME List . . . . . . . . . . . . . . . . . . . . . . . . 10
8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.7. Presence Status . . . . . . . . . . . . . . . . . . . . . 10
8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 12 4.8. Rule Deactivated . . . . . . . . . . . . . . . . . . . . . 10
8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 12 4.9. Time Period Condition . . . . . . . . . . . . . . . . . . 10
8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 12 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Execute Action . . . . . . . . . . . . . . . . . . . . . . 18
8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 13 5.2. Forward To . . . . . . . . . . . . . . . . . . . . . . . . 18
8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 13 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 13 7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 13 8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 13 8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 13 8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 27
9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 14 8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 27
9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 14 8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 27
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 28
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . . 15 9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 18 9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 29
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30
13.1. Normative References . . . . . . . . . . . . . . . . . . . 30
13.2. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . . . . 36
1. Introduction 1. Introduction
The problem of SPAM for Internet Telephony (SPIT) is an imminent The problem of SPAM for Internet Telephony (SPIT) is an imminent
challenge and only the combination of several techniques can provide challenge and only the combination of several techniques can provide
a framework for dealing with unwanted communication, as stated in a framework for dealing with unwanted communication, as stated in
[11]. [I-D.jennings-sip-hashcash].
One important building block is to have a mechanism that can instruct One important building block is to have a mechanism that can instruct
SIP intermediaries to react differently on incoming requests based on SIP intermediaries to react differently on incoming requests based on
policies. Different entities, such as end users, parents on behalf policies. Different entities, such as end users, parents on behalf
of their children, system administrators in enterprise networks, of their children, system administrators in enterprise networks,
etc., might create and modify authorization policies. The conditions etc., might create and modify authorization policies. The conditions
in these policies can be created from many sources but some in these policies can be created from many sources but some
information elements are more important than others. For example, information elements are more important than others. For example,
there is reason to believe that applying authorization policies based there is reason to believe that applying authorization policies based
on the authenticated identity is an effective way to accept a on the authenticated identity is an effective way to accept a
communication attempt to deal with unsolicited communication. communication attempt to deal with unsolicited communication.
Authentication based on the SIP identity mechanism, see [2], is one Authentication based on the SIP identity mechanism, see [RFC4474], is
important concept. one important concept.
There is also related work in this context that needs to be The requirements for the authorization policies described in this
highlighted. Requirements for the authorization policies described document are outlined in [I-D.froment-sipping-spit-requirements]. A
in this document are outlined in [7]. Selected parts of the work framework document is available at
done with Sieve [13], a mail filtering language, may be reused by [I-D.tschofenig-sipping-framework-spit-reduction].
this document. Furthermore, the Call Processing Language (CPL) [14]
is similar to the approach described in this document. The
difference mainly is that CPL has a more procedural approach, while
this proposal is matching-based.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document reuses the terminology from RFC 4745 [3]: This document reuses the terminology from RFC 4745 [RFC4745]:
Rule maker: Rule maker:
The RM is an entity that creates the authorization policies that The RM is an entity that creates the authorization policies that
react to unwanted connection attempts. The rule maker might be an react to unwanted connection attempts. The rule maker might be an
end user that owns the device, a VoIP service provider, a person end user that owns the device, a VoIP service provider, a person
with a relationship to the end user (e.g., the parents of a child with a relationship to the end user (e.g., the parents of a child
using a mobile phone). A standardized policy language is needed using a mobile phone). A standardized policy language is needed
when the creation, modification and deletion of authorization when the creation, modification and deletion of authorization
policies are not only a local matter. policies are not only a local matter.
skipping to change at page 5, line 20 skipping to change at page 5, line 20
'authorization policy', 'policy', 'rule set', 'authorization 'authorization policy', 'policy', 'rule set', 'authorization
policy rule', 'policy rule' and 'rule' are used interchangeably. policy rule', 'policy rule' and 'rule' are used interchangeably.
Authorization policies can be applied at the end host and/or by Authorization policies can be applied at the end host and/or by
intermediaries. intermediaries.
Permission: Permission:
The term permission refers to the action and transformation The term permission refers to the action and transformation
components of a rule. components of a rule.
We use the term 'Recipient' for the entity that is target of the
communication attempt of a sender.
3. Generic Processing 3. Generic Processing
3.1. Structure of SPIT Authorization Documents 3.1. Structure of SPIT Authorization Documents
A SPIT authorization document is an XML document, formatted according A SPIT authorization document is an XML document, formatted according
to the schema defined in RFC 4745 [3]. SPIT authorization documents to the schema defined in RFC 4745 [RFC4745]. SPIT authorization
inherit the MIME type of common policy documents, application/ documents inherit the MIME type of common policy documents,
auth-policy+xml. As described in [3], this document is composed of application/auth-policy+xml. As described in [RFC4745], this
rules which contain three parts - conditions, actions, and document is composed of rules which contain three parts - conditions,
transformations. Each action or transformation, which is also called actions, and transformations. Each action or transformation, which
a permission, has the property of being a positive grant to the is also called a permission, has the property of being a positive
authorization server to perform the resulting actions, be it allow, grant to the authorization server to perform the resulting actions,
block etc . As a result, there is a well-defined mechanism for be it allow, block etc . As a result, there is a well-defined
combining actions and transformations obtained from several sources. mechanism for combining actions and transformations obtained from
This mechanism therefore can be used to filter connection attempts several sources. This mechanism therefore can be used to filter
thus leading to effective SPIT prevention. connection attempts thus leading to effective SPIT prevention.
3.2. Rule Transport 3.2. Rule Transport
Policies are XML documents that are stored at a Proxy Server or a Policies are XML documents that are stored at a Proxy Server or a
dedicated device. The Rule Maker therefore needs to use a protocol dedicated device. The Rule Maker therefore needs to use a protocol
to create, modify and delete the authorization policies defined in to create, modify and delete the authorization policies defined in
this document. Such a protocol is available with the Extensible this document. Such a protocol is available with the Extensible
Markup Language (XML) Configuration Access Protocol (XCAP) [4]. Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825].
4. Condition Elements 4. Condition Elements
This section describes the additional enhancements of the conditions- This section describes the additional enhancements of the conditions-
part of the rule. This document inherits the Common Policy part of the rule. This document inherits the Common Policy
functionality, including identity, validity, and sphere conditions. functionality, including <identity>, <validity>, and <sphere>
conditions.
The identity condition restricts matching of a rule either to a Note that, as discussed in [RFC4745], a permission document applies
single entity or a group of entities. Authenticated and non- to a translation if all the expressions in its conditions part
authenticated entities can be matched; acceptable means of evaluate to TRUE.
authentication are specified in Section 3.1 of [10] and can be reused
in this document. An important component of the overall solution are
authenticated identities, such as provided via SIP Identity [2]. If
the <identity> element is absent, identities are not considered, and
thus, other conditions in the rule apply to any user, authenticated
or not.
The <identity> condition is considered TRUE if any of its child 4.1. Identity
elements (e.g., the <one> and the <many> elements defined in this
document) evaluate to TRUE, i.e., the results of the individual child Although the <identity> element is defined in [RFC4745], that
specification indicates that the specific usages of the framework
document need to define details that are protocol and usage specific.
In particular, it is necessary for a usage of the common policy
framework to:
o Define acceptable means of authentication.
o Define the procedure for representing the identity as a URI or IRI
[RFC3987].
This sub-section defines those details for systems based on
[RFC3856].
4.1.1. Acceptable Forms of Authentication
When used with SIP, a request is considered authenticated if one of
the following techniques is used:
SIP Digest:
The proxy has authenticated the sender using SIP [RFC3261] digest
authentication [RFC2617]. However, if the anonymous
authentication described on page 194 of RFC 3261 [RFC3261] was
used, the sender is not considered authenticated.
Asserted Identity:
If a request contains a P-Asserted-ID header field [RFC3325] and
the request is coming from a trusted element, the sender is
considered authenticated.
Cryptographically Verified Identity:
If a request contains an Identity header field as defined in
[RFC4474], and it validates the From header field of the request,
the request is considered to be authenticated. Note that this is
true even if the request contained a From header field of the form
sip:anonymous@example.com. As long as the signature verifies that
the request legitimately came from this identity, it is considered
authenticated.
An anonymous From header field with RFC 4474 [RFC4474] is considered
authenticated, while anonymous digest is not considered
authenticated, because the former still involves the usage of an
actual username and credential as part of an authentication operation
in the originating domain.
4.1.2. Computing a URI for the Sender
For messages that are authenticated using SIP Digest, the identity of
the sender is set equal to the address of record (AoR) for the user
that has authenticated themselves. The AoR is always a URI, and can
be either a SIP URI or tel URI [RFC3966]. For example, consider the
following "user record" in a database:
SIP AOR: sip:alice@example.com
digest username: ali
digest password: f779ajvvh8a6s6
digest realm: example.com
If the proxy server receives an INVITE, challenges it with the realm
set to "example.com", and the subsequent INVITE contains an
Authorization header field with a username of "ali" and a digest
response generated with the password "f779ajvvh8a6s6", the identity
used in matching operations is "sip:alice@example.com".
For messages that are authenticated using RFC 3325 [RFC3325], the
identity of the sender is equal to the URI in the P-Asserted-ID
header field. If there are multiple values for the P-Asserted-ID
header field (there can be one sip URI and one tel URI [RFC3966]),
then each of them is used for the comparisons outlined in [RFC4745],
and if either of them match a <one> or <except> element, it is
considered a match.
For messages that are authenticated using the SIP Identity mechanism
[RFC4474], identity of the sender is equal to the SIP URI in the From
header field of the request, assuming that the signature in the
Identity header field has been validated.
In SIP systems, it is possible for a user to have aliases - that is,
there are multiple SIP AoRs "assigned" to a single user. In terms of
this specification, there is no relationship between those aliases.
Each would look like a different user. This will be the consequence
for systems where the sender is in a different domain than the
recipient. However, even if the sender and recipient are in the same
domain, and the proxy server knows that there are aliases for the
sender, these aliases are not mapped to each other or used in any
way.
SIP also allows for anonymous identities. If a message is anonymous
because the digest challenge/response used the "anonymous" username,
the message is considered unauthenticated and will match only an
empty <identity> element. If a message is anonymous because it
contains a Privacy header field [RFC3323], but still contains a
P-Asserted-ID header field, the identity in the P-Asserted-ID header
field is still used in the authorization computations; the fact that
the message was anonymous has no impact on the identity processing.
However, if the message had traversed a trust boundary and the
P-Asserted-ID header field and the Privacy header field had been
removed, the message will be considered unauthenticated when it
arrives at the proxy server. Finally, if a message contained an
Identity header field that was validated, and the From header field
contained a URI of the form sip:anonymous@example.com, then the
sender is considered authenticated, and it will have an identity
equal to sip:anonymous@example.com. Had such an identity been placed
into a <one> or <except> element, there will be a match.
It is important to note that SIP frequently uses both SIP URI and tel
URI [RFC3966] as identifiers, and to make matters more confusing, a
SIP URI can contain a phone number in its user part, in the same
format used in a tel URI. The sender's identity that is a SIP URI
with a phone number will not match the <one> and <except> conditions
whose 'id' is a tel URI with the same number. The same is true in
the reverse. If the sender's identity is a tel URI, this will not
match a SIP URI in the <one> or <except> conditions whose user part
is a phone number. URIs of different schemes are never equivalent.
4.2. Sphere
The <sphere> element is defined in [RFC4745]. However, each
application making use of the common policy specification needs to
determine how the policy server computes the value of the sphere to
be used in the evaluation of the condition.
To compute the value of <sphere>, the proxy server interacts with a
presence server who knows whether at least one of the published
presence documents includes the <sphere> element [RFC4480] as part of
the person data component [RFC4479], and all of those containing the
element have the same value for it, that is the value used for the
sphere in policy policy processing. If, however, the <sphere>
element was not available to the presence server (and hence not for
the proxy server), or it was present but had inconsistent values, its
value is considered undefined in terms of policy processing.
4.3. SPIT Handling
The <spit-handling> element is a way to react on the execution of
certain SPIT handling mechanisms. For example, a rule might indicate
that a CAPTCHA has to be sent to the sender and the sender
subsequently has to return the result. Depending on the outcome of
the robot test the rules might enforce different actions. This
element provides such a condition capability.
The <spit-handling> condition evaluates to TRUE if any of its child
elements evaluate to TRUE, i.e., the results of the individual child
element are combined using a logical OR. element are combined using a logical OR.
4.1. MessagePattern Element The <spit-handling> element MAY contain zero or more <challenge>
elements. The <challenge> elements has an attribute 'result' that
either contains "SUCCESS" or "FAILURE".
Any attribute of the SIP header, such as the From, To, Contact etc., 4.4. Media List
can be used to perform actions on incoming messages.
4.2. MethodUsed Element The <media-list> condition evaluates to TRUE if any of its child
elements evaluate to TRUE, i.e., the results of the individual child
element are combined using a logical OR.
Any SIP Method invoked by the user can be used to filter incoming The <media-list> element SHOULD include either
messages. o an <all-media-except> element or;
o a list of one or more >media> elements selected from the list of
possible media elements below.
4.3. Assertions-Specific Parameters List of possible media elements:
o The <message-session> media element indicating session based
messaging as defined in [I-D.ietf-simple-message-sessions];
o The <pager-mode-message> media element indicating pager mode
message requests as defined in [RFC3428];
o The <file-transfer> media element indicating file transfer as
defined in [I-D.ietf-mmusic-file-transfer-mech];
o The <audio> media element indicating a streaming media type as
defined in [RFC3840];
o The <video> media element indicating a streaming media type as
defined in [RFC3840];
This parameter list set refers to information that can be made o Any elements from any other namespaces defining a media element.
available by, for example, using SAML assertions, as defined in [5].
As an example, the following attribute is reused in this document:
AuthenticationOfAccountOpening: The <all-media-except> element MAY include a list of one or more
>media> elements selected from the list of possible >media> elements
above.
(a) No validation of new account (could be machine opened) The <audio>, <video> and <message-session> elements:
(b) Turing Test (human needed to open new account) o MAY include the <full-duplex> element indicating that media can be
(c) Credit card or other form of verifiable identification exchanged in both directions simultaneously;
(d) Passport was presented for verification o MAY include the <half-duplex> element indicating that media can be
exchanged in only one direction at a time.
The values put in the element are defined as follows: 4.5. Method List
o
Corresponds to value (a)- (d) The <method-list> element contains one or more child elements
o <method> in order to provide matching capabilities of any SIP method
invoked by the user can be used to filter incoming messages.
Corresponds to value (b) - (d) The <method-list> condition element evaluates to TRUE if any of its
o child elements evaluate to TRUE, i.e., the results of the individual
child element are combined using a logical OR.
Corresponds to value (c) - (d) 4.6. MIME List
o The <mime-list> element contains one or more child <mime> child
elements
Corresponds to value (d) The <mime-list> condition element evaluates to TRUE if any of its
child elements evaluate to TRUE, i.e., the results of the individual
child element are combined using a logical OR.
Other attributes, such as IdentityStrength, CostOfCall, 4.7. Presence Status
IdentityAssertion, ConnectionSecurity, SPITSuspected, CallCenter, or
AssertionStrength from [5] might allow meaningful decisions to be
performed.
Further parameters carried in a SAML assertion are defined in [6] and This condition evaluates to TRUE when the called user's current
can also be used for the decision making process. Possible presence activity status is equal to the value in the <presence-
parameters for Originating Line Indication (OLI) and for Calling status> element. Otherwise the condition evaluates to FALSE.
Party Category (CPC) are described in Section 7 and 8 of [6]. The
CPC parameters may also be encoded in a different form, as shown in 4.8. Rule Deactivated
[8], and usable by this document.
The <rule-deactivated> condition always evaluates to FALSE. This can
be used to deactivate a rule, without loosing information. By
removing this condition the rule can be activated again.
4.9. Time Period Condition
The <time-period> element allows to make decisions based on the time,
date and timezone. The <time> element may contain the following
attributes:
tzid:
RFC 2445 [RFC2445] Time Zone Identifier
tzurl:
RFC 2445 [RFC2445] Time Zone URL
dtstart:
Start of interval (RFC 2445 [RFC2445] DATE-TIME)
dtend:
End of interval (RFC 2445 [RFC2445] DATE-TIME)
duration:
Length of interval (RFC 2445 [RFC2445] DURATION)
freq:
Frequency of recurrence ("secondly", "minutely", "hourly",
"daily", "weekly", "monthly", or "yearly")
interval:
How often the recurrence repeats
until:
Bound of recurrence (RFC 2445 [RFC2445] DATE-TIME)
count:
Number of occurrences of recurrence
bysecond:
List of seconds within a minute
byminute:
List of minutes within an hour
byhour:
List of hours of the day
byday: List of days of the week
bymonthday:
List of days of the month
byyearday:
List of days of the year
byweekno:
List of weeks of the year
bymonth:
List of months of the year
wkstv:
First day of the work week
bysetpos:
List of values within set of events specified
The <time-period> is based on the description in CPL [RFC3880] and
furthemore based closely on the specification of recurring intervals
of time in the Internet Calendaring and Scheduling Core Object
Specification (iCalendar COS), RFC 2445 [RFC2445].
This allows policies to be generated automatically from calendar
books. It also allows us to re-use the extensive existing work
specifying time intervals.
If future standards-track documents are published that update or
obsolete RFC 2445 [RFC2445], any changes or clarifications those
documents make to recurrence handling apply to CPL time-switches as
well.
An algorithm to determine whether an instant falls within a given
recurrence is given in Appendix A of RFC 3880 [RFC3880].
The <time-period> element takes two optional attributes, "tzid" and
"tzurl", both of which are defined in Sections 4.8.3.1 and 4.8.3.5 of
RFC 2445 [RFC2445]. The "tzid" is the identifying attribute by which
a time zone definition is referenced. If it begins with a forward
slash (solidus), it references a to-be-defined global time zone
registry; otherwise it is locally-defined at the server. The "tzurl"
attribute gives a network location from which an up-to-date VTIMEZONE
definition for the timezone can be retrieved.
While the content of the "tzid" attribute does not begin with a
forward slash are locally defined, it is RECOMMENDED that servers
support at least the naming scheme used by the Olson Time Zone
database [OTZ]. Examples of timezone databases that use the Olson
scheme are the zoneinfo files on most Unix-like systems, and the
standard Java TimeZone class.
Servers SHOULD resolve "tzid" and "tzurl" references to time zone
definitions at the time the policy is uploaded. They MAY
periodically refresh these resolutions to obtain the most up-to-date
definition of a time zone. If a "tzurl" becomes invalid, servers
SHOULD remember the most recent valid data retrieved from the URL.
If a script is uploaded with a "tzid" and "tzurl" which the CPL
server does not recognize or cannot resolve, it SHOULD diagnose and
reject this at script upload time. If neither "tzid" nor "tzurl" are
present, all non-UTC times within this time switch should be
interpreted as being "floating" times, i.e., that they are specified
in the local timezone of the CPL server.
Because of daylight-savings-time changes over the course of a
year, it is necessary to specify time switches in a given
timezone. UTC offsets are not sufficient, or a time-of-day
routing rule which held between 9 am and 5 pm in the eastern
United States would start holding between 8 am and 4 pm at the end
of October.
The developers of tools used creating policy documents should be
careful to handle correctly the intervals when local time is
discontinuous, at the beginning or end of daylight-savings time.
Note especially that some times may occur more than once when clocks
are set back. The algorithm in Appendix A of RFC 3880 [RFC3880] is
believed to handle this correctly.
The <time> element specifies a list of periods. They have two
required attributes a:
o "dtstart", which specifies the beginning of the first period of
the list,
o and exactly one of "dtend" or "duration", which specify the ending
time or the duration of the period, respectively.
The "dtstart" and "dtend" attributes are formatted as iCalendar COS
DATE-TIME values, as specified in Section 4.3.5 of RFC 2445
[RFC2445]. Only floating or UTC times can be used with time zones.
The "duration" attribute is given as an iCalendar COS DURATION
parameter, as specified in section 4.3.6 of RFC 2445 [RFC2445]. Both
the DATE-TIME and the DURATION syntaxes are subsets of the
corresponding syntaxes from ISO 8601 [ISO8601].
For a recurring interval, the "duration" attribute MUST be small
enough such that subsequent intervals do not overlap. For non-
recurring intervals, durations of any positive length are permitted.
Zero-length and negative-length durations are not allowed.
If no other parameters are specified, a <time> element indicates only
a single period of time. More complicated sets of period intervals
are constructed as recurrences. A recurrence is specified by
including the "freq" attribute, which indicates the type of
recurrence rule. Parameters other than "dtstart", "dtend", and
"duration" SHOULD NOT be specified unless "freq" is present, though
servers SHOULD accept rules with such parameters present, and ignore
the other parameters.
The "freq" parameter takes one of the following values: "secondly",
to specify repeating periods based on an interval of a second or
more, "minutely", to specify repeating periods based on an interval
of a minute or more, "hourly", to specify repeating periods based on
an interval of an hour or more, "daily", to specify repeating periods
based on an interval of a day or more, "weekly", to specify repeating
periods based on an interval of a week or more, "monthly", to specify
repeating periods based on an interval of a month or more, and
"yearly", to specify repeating periods based on an interval of a year
or more. These values are not case-sensitive.
The "interval" attribute contains a positive integer representing how
often the recurrence rule repeats. The default value is "1", meaning
every second for a "secondly" rule, every minute for a "minutely"
rule, every hour for an "hourly" rule, every day for a "daily" rule,
every week for a "weekly" rule, every month for a "monthly" rule, and
every year for a "yearly" rule.
The "until" attribute defines an iCalendar COS DATE or DATE-TIME
value which bounds the recurrence rule in an inclusive manner. If
the value specified by "until" is synchronized with the specified
recurrence, this date or date-time becomes the last instance of the
recurrence. If specified as a date-time value, then it MUST be
specified in UTC time format. If not present, and the "count"
parameter is not also present, the recurrence is considered to repeat
forever.
The "count" attribute defines the number of occurrences at which to
range-bound the recurrence. The "dtstart" attribute counts as the
first occurrence. The "until" and "count" attribute MUST NOT occur
in the same <time> element.
The "bysecond" attribute specifies a comma-separated list of seconds
within a minute. Valid values are 0 to 59. The "byminute" attribute
specifies a comma-separated list of minutes within an hour. Valid
values are 0 to 59. The "byhour" attribute specifies a comma-
separated list of hours of the day. Valid values are 0 to 23.
The "byday" attribute specifies a comma-separated list of days of the
week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" indicates
Wednesday, "TH" indicates Thursday, "FR" indicates Friday, "SA"
indicates Saturday, and "SU" indicates Sunday. These values are not
case-sensitive.
Each "byday" value can also be preceded by a positive (+n) or
negative (-n) integer. If present, this indicates the nth occurrence
of the specific day within the "monthly" or "yearly" recurrence. For
example, within a "monthly" rule, +1MO (or simply 1MO) represents the
first Monday within the month, whereas -1MO represents the last
Monday of the month. If an integer modifier is not present, it means
all days of this type within the specified frequency. For example,
within a "monthly" rule, MO represents all Mondays within the month.
The "bymonthday" attribute specifies a comma-separated list of days
of the month. Valid values are 1 to 31 or -31 to -1. For example,
-10 represents the tenth to the last day of the month.
The "byyearday" attribute specifies a comma-separated list of days of
the year. Valid values are 1 to 366 or -366 to -1. For example, -1
represents the last day of the year (December 31st) and -306
represents the 306th to the last day of the year (March 1st).
The "byweekno" attribute specifies a comma-separated list of ordinals
specifying weeks of the year. Valid values are 1 to 53 or -53 to -1.
This corresponds to weeks according to week numbering as defined in
ISO 8601 [ISO8601]. A week is defined as a seven day period,
starting on the day of the week defined to be the week start (see
"wkst"). Week number one of the calendar year is the first week
which contains at least four (4) days in that calendar year. This
parameter is only valid for "yearly" rules. For example, 3
represents the third week of the year.
Note: Assuming a Monday week start, week 53 can only occur when
January 1 is a Thursday or, for leap years, if January 1 is a
Wednesday.
The "bymonth" attribute specifies a comma-separated list of months of
the year. Valid values are 1 to 12.
The "wkst" attribute specifies the day on which the work week starts.
Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". This
is significant when a "weekly" recurrence has an interval greater
than 1, and a "byday" parameter is specified. This is also
significant in a "yearly" recurrence when a "byweekno" parameter is
specified. The default value is "MO", following ISO 8601 [ISO8601].
The "bysetpos" attribute specifies a comma-separated list of values
which corresponds to the nth occurrence within the set of events
specified by the rule. Valid values are 1 to 366 or -366 to -1. It
MUST only be used in conjunction with another byxxx attribute. For
example, "the last work day of the month" could be represented as:
<time dtstart="19970105T083000"
freq="monthly"
byday="MO,TU,WE,TH,FR"
bysetpos="-1"
/>
Each "bysetpos" value can include a positive (+n) or negative (-n)
integer. If present, this indicates the nth occurrence of the
specific occurrence within the set of events specified by the rule.
If byxxx attribute values are found which are beyond the available
scope (i.e., bymonthday="30" in February), they are simply ignored.
Byxxx attribute modify the recurrence in some manner. Byxxx rule
parts for a period of time which is the same or greater than the
frequency generally reduce or limit the number of occurrences of the
recurrence generated. For example, freq="daily" bymonth="1" reduces
the number of recurrence instances from all days (if the "bymonth"
attribute is not present) to all days in January. Byxxx attribute
for a period of time less than the frequency generally increase or
expand the number of occurrences of the recurrence. For example,
freq="yearly" bymonth="1,2" increases the number of days within the
yearly recurrence set from 1 (if "bymonth" parameter is not present)
to 2.
If multiple Byxxx attribute are specified, then after evaluating the
specified "freq" and "interval" attribute, the Byxxx attribute are
applied to the current set of evaluated occurrences in the following
order: "bymonth", "byweekno", "byyearday", "bymonthday", "byday",
"byhour", "byminute", "bysecond", and "bysetpos"; then "count" and
"until" are evaluated.
Here is an example of evaluating multiple Byxxx attribute.
<time dtstart="19970105T083000"
duration="10M"
freq="yearly"
interval="2"
bymonth="1"
byday="SU"
byhour="8,9"
byminute="30">
/>
First, the interval="2" would be applied to freq="yearly" to arrive
at "every other year." Then, bymonth="1" would be applied to arrive
at "every January, every other year." Then, byday="SU" would be
applied to arrive at "every Sunday in January, every other year."
Then, byhour="8,9" would be applied to arrive at "every Sunday in
January at 8 AM and 9 AM, every other year." Then, byminute="30"
would be applied to arrive at "every Sunday in January at 8:30 AM and
9:30 AM, every other year." Then the second is derived from
"dtstart" to end up in "every Sunday in January from 8:30:00 AM to
8:40:00 AM, and from and 9:30:00 AM to 9:40:00 AM, every other year."
Similarly, if the "byminute", "byhour", "byday", "bymonthday", or
"bymonth" parameter were missing, the appropriate minute, hour, day,
or month would have been retrieved from the "dtstart" parameter.
The iCalendar COS RDATE, EXRULE, and EXDATE recurrence rules are not
specifically mapped to components of the <time-period> element.
Equivalent functionality to the exception rules can be attained by
using the ordering of rules to exclude times using earlier rules.
Section 4.4.1 of [RFC3880] provides some background of the
differences to iCalendar and implementation issues.
5. Actions 5. Actions
As stated in [2], conditions are the 'if'-part of rules, whereas As stated in [RFC4474], conditions are the 'if'-part of rules,
actions and transformations form their 'then'-part. The actions and whereas actions and transformations form their 'then'-part. The
transformations parts of a rule determine which operations the proxy actions and transformations parts of a rule determine which
server MUST execute on receiving a connection request attempt that operations the proxy server MUST execute on receiving a connection
matches all conditions of this rule. Actions and transformations request attempt that matches all conditions of this rule. Actions
permit certain operations such as block, polite-block, mark, allow, and transformations permit certain operations to be executed.
puzzle and consent.
5.1. Handling Action 5.1. Execute Action
The <handling> element allows a couple of actions to be defined. The <handling> element allows a couple of actions to be triggered,
namely
Block Action: Block Action:
The block action states that this specific connection request MUST The block action states that this specific connection request MUST
NOT be forwarded and a "403" forbidden message MUST be sent to the NOT be forwarded and a "403" forbidden message MUST be sent to the
sender of the message. sender of the message.
Polite-block Action
The Polite-block action states that this specific connection
request MUST NOT be forwarded and no message be sent back to the
sender of the message.
Mark Action:
The Mark action states that this specific connection request MUST
be forwarded after marking it as a "SPAM". Details for the
message marking are for further study.
Allow Action: Allow Action:
The Allow action states that this specific connection request MUST The Allow action states that this specific connection request MUST
be forwarded. be forwarded.
Puzzle Action:
The Puzzle action states that the "Computational Puzzles" Furthermore, a couple of further mechanisms, such as computational
mechanism, described in [11], MUST be triggered. puzzles mechanism (described in [I-D.jennings-sip-hashcash]), the
consent framework (described in [I-D.ietf-sip-consent-framework])
Consent Action: etc. can be executed. Each mechanism needs to register a URI and the
value of URI is placed in this field.
The Consent action states that "Consent Framework" [12] mechanism [Editior's Note: For editorial purposes the schema currently lists a
MUST be triggered. few examples but in a non-URI format. When solution documents define
these URIs then they can be used with this document.]
Default Action: 5.2. Forward To
One of the action can be stated as a default action. The action supported in this section is forwarding of calls with the
<forward-to> element that contains the following child elements:
5.2. Redirect Action target:
This document defines the <redirect> action that contains a URI where Specifies the address of the forwarding rule. It should be a
an incoming message is forwarded to. valid SIP URI (RFC 3261 [RFC3261]) or TEL URI (RFC 3966
[RFC3966]).
6. Examples 6. Examples
This section provides a few examples for policy rules defined in this This section provides a few examples for policy rules defined in this
document. The example policy shows three rules with the rule id 1, 2 document. The example policy shows three rules with the rule id r1 -
and 3. The rule with the id=1 matches for authenticated identities r4.
from the domain "example.com", "example.org" and the single identity
"sip:bob@good.example.net". For these conditions SIP messages are
forwarded to the SIP UA as indicated with the <handling> element.
Rule 2 indicates that for SIP messages where the identity cannot be Rule r1 matches for authenticated identities from the domain
matched against a white list and for those where the identity was "example.com", "example.org" and the single identity
obtained by having the user to present a passport, credit card or "sip:bob@good.example.net". For these conditions SIP messages are
other form of verifiable identification when opening the account (as forwarded to the SIP UA as indicated with the <handling> element.
indicated in the <AuthenticationOfAccountOpening> by setting the
token 'VERIFYABLE') the consent framework is applied (see 'consent'
token in the <handling> element).
Rule 1 and 2 are valid only from 2007-1-24T17:00:00+01:00 to 2007-3- Rule r2 indicates that for SIP messages where the identity has not
24T19:00:00+01:00. been verifiable the hash cash mechanism
[I-D.jennings-sip-hashcash] and CAPTCHAs
[I-D.tschofenig-sipping-captcha] are applied (see the 'hashcash'
and the 'captcha' token in the <execute> element).
Rule r3 contains the <spit-handling> element with the <challenge>
child element. This rule evaluates to TRUE if the sender returned
a valid hash cash or a valid CAPTCHA result. The action part of
the rule indicates that the call is then forwarded to the
answering machine, namely sip:answering-machine@home.foo-bar.com.
Rule r4 blocks the call if sender provided a wrong hash cash or
CAPTCHA result.
Rule 3 does not contain any condition. All requests that fall into Rule r1 and r2 are valid only from 2007-01-01T01:00:00+01:00 to 2007-
this category are redirected to an answering machine (namely 07-01T24:00:00+01:00.
sip:answering-machine@home.foo-bar.com). Rule 3 is not restricted to
a specific time period.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy" <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:spit="urn:ietf:params:xml:ns:spit-policy" xmlns:spit="urn:ietf:params:xml:ns:spit-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="1"> <rule id="r1">
<conditions> <conditions>
<identity> <identity>
<one id="sip:bob@good.example.net"/> <one id="sip:bob@good.example.net"/>
<many domain="example.com"/> <many domain="example.com"/>
<many domain="example.org"/> <many domain="example.org"/>
</identity> </identity>
<validity> <validity>
<from>2007-1-24T17:00:00+01:00</from> <from>2007-01-01T01:00:00+01:00</from>
<until>2007-3-24T19:00:00+01:00</until> <until>2007-07-01T24:00:00+01:00</until>
</validity> </validity>
</conditions> </conditions>
<actions> <actions>
<spit:handling>allow</spit:handling> <spit:execute>allow</spit:execute>
</actions> </actions>
<transformations/> <transformations/>
</rule> </rule>
<rule id="2"> <rule id="r2">
<conditions> <conditions>
<validity> <validity>
<from>2007-1-24T17:00:00+01:00</from> <from>2007-01-01T01:00:00+01:00</from>
<until>2007-3-24T19:00:00+01:00</until> <until>2007-07-01T24:00:00+01:00</until>
</validity> </validity>
<spit:AuthenticationOfAccountOpening>VERIFYABLE
</spit:AuthenticationOfAccountOpening>
</conditions> </conditions>
<actions> <actions>
<spit:handling>consent</spit:handling> <spit:execute>hashcash</spit:execute>
<spit:execute>captcha</spit:execute>
</actions> </actions>
<transformations/> <transformations/>
</rule> </rule>
<rule id="3"> <rule id="r3">
<conditions/> <conditions>
<spit:spit-handling>
<challenge result="SUCCESS">hashcash</challenge>
<challenge result="SUCCESS">captcha</challenge>
</spit:spit-handling>
</conditions>
<actions> <actions>
<spit:redirect>sip:answering-machine@home.foo-bar.com <spit:forward-to>
</spit:redirect> <target>sip:answering-machine@home.foo-bar.com
</target>
</spit:forward-to>
</actions>
<transformations/>
</rule>
<rule id="r4">
<conditions>
<spit:spit-handling>
<challenge result="FAILURE">hashcash</challenge>
<challenge result="FAILURE">captcha</challenge>
</spit:spit-handling>
</conditions>
<actions>
<spit:execute>block</spit:execute>
</actions> </actions>
<transformations/> <transformations/>
</rule> </rule>
</ruleset> </ruleset>
7. XML Schema 7. XML Schema
This section contains the XML schema that defines the policies schema This section contains the XML schema that defines the policies schema
described in this document. This schema extends the Common Policy described in this document. This schema extends the Common Policy
schema (see [2]) by introducing new members of the <condition> and schema (see [RFC4474]) by introducing new members of the <condition>
<action> elements. and <action> elements.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema <xs:schema targetNamespace="urn:ietf:params:xml:ns:spit-policy"
targetNamespace="urn:ietf:params:xml:ns:spit-policy"
xmlns:spit="urn:ietf:params:xml:ns:spit-policy" xmlns:spit="urn:ietf:params:xml:ns:spit-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang--> <!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace" <xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/> schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- Conditions --> <xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<xs:element name="MethodUsed"
type="xs:string"/>
<xs:element name="CostOfCall" <!-- Conditions -->
type="xs:integer" default="0"/>
<xs:element name="IdentityStrength" <xs:element name="method-list">
type="xs:integer" default="0"/> <xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="method" type="spit:method-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="AuthenticationOfAccountOpening"> <xs:element name="spit-handling">
<xs:complexType>
<xs:sequence>
<xs:element name="challenge" type="spit:challenge-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="result" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="SUCCESS"/>
<xs:enumeration value="FAILURE"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType> </xs:attribute>
<xs:restriction base="xs:token"> </xs:complexType>
<xs:enumeration value="NO_EFFORT"/>
<xs:enumeration value="HUMAN"/>
<xs:enumeration value="VERIFYABLE"/>
<xs:enumeration value="PASSPORT"/>
</xs:restriction>
</xs:simpleType>
</xs:element> </xs:element>
<xs:element name="MessagePattern"> <xs:element name="mime-list">
<xs:complexType> <xs:complexType>
<xs:attribute name="context" /> <xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="mime" type="spit:mime-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType> </xs:complexType>
</xs:element>
<xs:element name="media-list">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="media" type="spit:media-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element> </xs:element>
<!-- Action --> <xs:element name="rule-deactivated"
type="spit:empty-element-type"/>
<xs:element name="handling"> <xs:complexType name="empty-element-type"/>
<xs:simpleType>
<xs:restriction base="xs:token"> <xs:element name="presence-status"
<xs:enumeration value="block"/> type="spit:presence-status-activity-type"/>
<xs:enumeration value="mark"/>
<xs:enumeration value="polite-block"/> <xs:simpleType name="presence-status-activity-type">
<xs:enumeration value="allow"/> <xs:restriction base="xs:string"/>
<xs:enumeration value="puzzle"/> </xs:simpleType>
<xs:enumeration value="consent"/>
<xs:simpleType name="media-type">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="challenge-type">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="mime-type">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="method-type">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:element name="time-period" type="spit:TimeSwitchType"/>
<xs:simpleType name="YearDayType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="-366"/>
<xs:maxInclusive value="-1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxExclusive value="366"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="DayType">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern value="[m|M][o|O]"/>
<xs:pattern value="[t|T][u|U]"/>
<xs:pattern value="[w|W][e|E]"/>
<xs:pattern value="[t|T][h|H]"/>
<xs:pattern value="[f|F][r|R]"/>
<xs:pattern value="[s|S][a|A]"/>
<xs:pattern value="[s|S][u|U]"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="TimeType">
<xs:annotation>
<xs:documentation>Exactly one of the two attributes
"dtend" and "duration" must occur. None of
the attributes following freq are meaningful
unless freq appears. </xs:documentation>
</xs:annotation>
<xs:attribute name="dtstart" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="dtend" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="duration" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DURATION</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="freq" type="spit:FreqType" use="optional"/>
<xs:attribute name="interval"
type="xs:positiveInteger" default="1"/>
<xs:attribute name="until" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="count"
type="xs:positiveInteger" use="optional"/>
<xs:attribute name="bysecond"
type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of
seconds within a minute. Valid values are 0 to
59.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byminute"
type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of
minutes within an hour. Valid values are 0 to
59.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byhour" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of
hours of the day. Valid values are 0 to
23.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the week.
Valid values are "MO", "TU",
"WE", "TH", "FR", "SA" and "SU". These values are
not case-sensitive. Each can be preceded
by a positive (+n) or negative (-n) integer.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="bymonthday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the month.
Valid values are 1 to 31 or -31
to -1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byyearday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the year.
Valid values are 1 to 366 or
-366 to -1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byweekno" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of ordinals
specifying weeks of the year. Valid
values are 1 to 53 or -53 to -1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="bymonth" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of months of the year.
Valid values are 1 to
12.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="wkst" type="spit:DayType" default="MO"/>
<xs:attribute name="bysetpos" type="spit:YearDayType"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:simpleType name="TZIDType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="TZURLType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="TimeSwitchType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="time" type="spit:TimeType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="tzid" type="spit:TZIDType"/>
<xs:attribute name="tzurl" type="spit:TZURLType"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:complexContent>
</xs:element> </xs:complexType>
<xs:element name="redirect" type="xs:string" /> <xs:simpleType name="FreqType">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern value="[s|S][e|E][c|C][o|O][n|N][d|D][l|L][y|Y]"/>
<xs:pattern value="[m|M][i|I][n|N][u|U][t|T][e|E][l|L][y|Y]"/>
<xs:pattern value="[h|H][o|O][u|U][r|R][l|L][y|Y]"/>
<xs:pattern value="[d|D][a|A][i|I][l|L][y|Y]"/>
<xs:pattern value="[w|W][e|E][e|E][k|K][l|L][y|Y]"/>
<xs:pattern value="[m|M][o|N][n|N][t|T][h|H][l|L][y|Y]"/>
<xs:pattern value="[y|Y][e|E][a|A][r|R][l|L][y|Y]"/>
</xs:restriction>
</xs:simpleType>
<!-- Action -->
<xs:element name="execute">
<xs:simpleType>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="forward-to" type="spit:forward-to-type"/>
<xs:complexType name="forward-to-type">
<xs:sequence>
<xs:element name="target" type="spit:target-type"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="target-type">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
</xs:schema> </xs:schema>
8. XCAP USAGE 8. XCAP USAGE
The following section defines the details necessary for clients to The following section defines the details necessary for clients to
manipulate SPIT authorization documents from a server using XCAP. manipulate SPIT authorization documents from a server using XCAP.
8.1. Application Unique ID 8.1. Application Unique ID
skipping to change at page 14, line 20 skipping to change at page 29, line 4
and its last line is and its last line is
</xs:schema> </xs:schema>
9.2. Anti-SPIT Policy Namespace Registration 9.2. Anti-SPIT Policy Namespace Registration
URI: urn:ietf:params:xml:ns:spit-policy URI: urn:ietf:params:xml:ns:spit-policy
Registrant Contact: Hannes Tschofenig Registrant Contact: Hannes Tschofenig
(hannes.tschofenig@siemens.com). (hannes.tschofenig@siemens.com).
XML: XML:
9.3. XCAP Application Usage ID 9.3. XCAP Application Usage ID
This section registers an XCAP Application Usage ID (AUID) according This section registers an XCAP Application Usage ID (AUID) according
to the IANA procedures defined in . to the IANA procedures defined in [RFC4825].
Name of the AUID: spit-policy Name of the AUID: spit-policy
Description: Anti-SPIT privacy rules are documents that describe the Description: The rules defined in this documents describe ways to
Authorization policies that trigger reaction to unwanted connection react on unwanted and unsolicted communication (including Spam).
attempts.
10. Security Considerations 10. Security Considerations
This document aims to make it simple for users to influence the This document aims to make it simple for users to influence the
behavior of SIP message routing with an emphasis on SPIT prevention. behavior of SIP message routing with an emphasis on SPIT prevention.
This document proposes a strawman proposal for conditions and actions This document proposes a strawman proposal for conditions and actions
that might be useful when it comes to allowing a UA to tell its that might be useful when it comes to allowing a UA to tell its
proxies which messages it wants to receive and what tasks it wants proxies which messages it wants to receive and what tasks it wants
those proxies to perform before sending a SIP request to the UA. those proxies to perform before sending a SIP request to the UA.
A couple of requirements are described in [7] and a general A couple of requirements are described in
discussion about the available solution mechanisms is available with [I-D.froment-sipping-spit-requirements] and a general discussion
[9]. This document offers the ability to glue the different solution about the available solution mechanisms is available with
pieces together. [I-D.ietf-sipping-spam]. This document offers the ability to glue
the different solution pieces together.
Since this document uses the Common Policy framework it also inherits Since this document uses the Common Policy framework it also inherits
its capabilities, including the combining permission algorithm that its capabilities, including the combining permission algorithm that
is applied when multiple rules fire. Unauthorized access to the is applied when multiple rules fire. Unauthorized access to the
user's Anti-SPIT rules must be prevented to avoid the introduction of user's Anti-SPIT rules must be prevented to avoid the introduction of
security vulnerabilities. security vulnerabilities.
11. Contributors 11. Contributors
We would like to thank Mayutan Arumaithurai We would like to thank Mayutan Arumaithurai
(mayutan.arumaithurai@gmail.com) for his work on this document. (mayutan.arumaithurai@gmail.com) for his work on this document.
12. Acknowledgments 12. Acknowledgments
We would like to thank David Schwartz for his work on the "SAML SPIT" We would like to thank
draft. We would like to thank Miguel Garcia and Remi Denis-Courmont o Jonathan Rosenberg, David Schwartz and Dan York for sharing their
for their review comments. thoughts with us before the first version of this document was
written.
Finally, we would like to thank Jonathan Rosenberg, David Schwartz o Miguel Garcia and Remi Denis-Courmont for their review comments to
and Dan York for sharing their thoughts with us. the -00 version.
o Mayutan Arumaithurai for his editing help with the -00 version.
o Poikselka Miikka, Isomaki Markus, Jari Mutikainen, Jean-Marie
Stupka, and Antti Laurila for their comments and for pointing us
to specifications outside the IETF.
This document intentionally re-uses concept from existing documents.
In particular, we reused
o ideas from SIEVE [RFC3028], a mail filtering language.
o the text in Section 4.9 from the Call Processing Language (CPL)
[RFC3880]. The difference between CPL and this document is that
CPL has a more procedural approach, while this proposal is
matching-based.
o text in Section 4.1 from [I-D.ietf-simple-presence-rules].
o content of Section 5.2, Section 4.8 and Section 4.7 is reused from
[ETSI-TS-183-004].
o text of Section 4.4 from [OMA-TS-XDM_Shared_Policy]
13. References 13. References
13.1. Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", March 1997. Requirement Levels", March 1997.
[2] Peterson, J. and C. Jennings, "Enhancements for Authenticated [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Identity Management in the Session Initiation Protocol (SIP)", Leach, P., Luotonen, A., and L. Stewart, "HTTP
RFC 4474, August 2006. Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[3] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
J., and J. Rosenberg, "Common Policy: A Document Format for A., Peterson, J., Sparks, R., Handley, M., and E.
Expressing Privacy Preferences", RFC 4745, February 2007. Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[4] Rosenberg, J., "The Extensible Markup Language (XML) [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Configuration Access Protocol (XCAP)", Initiation Protocol (SIP)", RFC 3323, November 2002.
draft-ietf-simple-xcap-12 (work in progress), October 2006.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)", RFC 4480, July 2006.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745,
February 2007.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
13.2. Informative References 13.2. Informative References
[5] Schwartz, D., "SPAM for Internet Telephony (SPIT) Prevention [ETSI-TS-183-004]
using the Security Assertion Markup Language (SAML)", ETSI, "TS 183 004, Telecommunications and Internet
draft-schwartz-sipping-spit-saml-01 (work in progress), converged Services and Protocols for Advanced Networking
June 2006. (TISPAN); PSTN/ISDN simulation services: Communication
Diversion (CDIV); Protocol specification", 2007.
[6] Schubert, S., "Conveying CPC using the SAML", [I-D.froment-sipping-spit-requirements]
draft-schubert-sipping-saml-cpc-02 (work in progress), Froment, T., "Requirements for Authorization Policies to
July 2006. tackle Spam for Internet Telephony and Unwanted Traffic",
draft-froment-sipping-spit-requirements-00 (work in
progress), June 2007.
[7] Froment, T., "Authorization Policies for Preventing SPIT", [I-D.ietf-ecrit-service-urn]
draft-froment-sipping-spit-authz-policies-01 (work in Schulzrinne, H., "A Uniform Resource Name (URN) for
progress), June 2006. Services", draft-ietf-ecrit-service-urn-06 (work in
progress), March 2007.
[8] Mahy, R., "The Calling Party's Category tel URI Parameter", [I-D.ietf-mmusic-file-transfer-mech]
draft-mahy-iptel-cpc-05 (work in progress), October 2006. Garcia-Martin, M., "A Session Description Protocol (SDP)
Offer/Answer Mechanism to Enable File Transfer",
draft-ietf-mmusic-file-transfer-mech-03 (work in
progress), June 2007.
[9] Jennings, C. and J. Rosenberg, "The Session Initiation Protocol [I-D.ietf-simple-message-sessions]
(SIP) and Spam", draft-ietf-sipping-spam-03 (work in progress), Campbell, B., "The Message Session Relay Protocol",
October 2006. draft-ietf-simple-message-sessions-19 (work in progress),
February 2007.
[10] Rosenberg, J., "Presence Authorization Rules", [I-D.ietf-simple-presence-rules]
draft-ietf-simple-presence-rules-08 (work in progress), Rosenberg, J., "Presence Authorization Rules",
October 2006. draft-ietf-simple-presence-rules-09 (work in progress),
March 2007.
[11] Jennings, C., "Computational Puzzles for SPAM Reduction in [I-D.ietf-sip-consent-framework]
SIP", draft-jennings-sip-hashcash-04 (work in progress), Rosenberg, J., "A Framework for Consent-Based
March 2006. Communications in the Session Initiation Protocol (SIP)",
draft-ietf-sip-consent-framework-02 (work in progress),
July 2007.
[12] Rosenberg, J., "A Framework for Consent-Based Communications in [I-D.ietf-sipping-spam]
the Session Initiation Protocol (SIP)", Jennings, C. and J. Rosenberg, "The Session Initiation
draft-ietf-sip-consent-framework-01 (work in progress), Protocol (SIP) and Spam", draft-ietf-sipping-spam-04 (work
November 2006. in progress), February 2007.
[13] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, [I-D.jennings-sip-hashcash]
January 2001. Jennings, C., "Computational Puzzles for SPAM Reduction in
SIP", draft-jennings-sip-hashcash-05 (work in progress),
June 2007.
[14] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing [I-D.mahy-iptel-cpc]
Language (CPL): A Language for User Control of Internet Mahy, R., "The Calling Party's Category tel URI
Telephony Services", RFC 3880, October 2004. Parameter", draft-mahy-iptel-cpc-06 (work in progress),
March 2007.
[I-D.rosenberg-sipping-service-identification]
Rosenberg, J., "Identification of Communications Services
in the Session Initiation Protocol (SIP)",
draft-rosenberg-sipping-service-identification-02 (work in
progress), May 2007.
[I-D.schubert-sipping-saml-cpc]
Schubert, S., "Conveying CPC using the SAML",
draft-schubert-sipping-saml-cpc-02 (work in progress),
July 2006.
[I-D.schwartz-sipping-spit-saml]
Schwartz, D., "SPAM for Internet Telephony (SPIT)
Prevention using the Security Assertion Markup Language
(SAML)", draft-schwartz-sipping-spit-saml-01 (work in
progress), June 2006.
[I-D.tschofenig-sipping-captcha]
Tschofenig, H. and E. Leppanen, "Completely Automated
Public Turing Test to Tell Computers and Humans Apart
(CAPTCHA) based Robot Challenges for the Session
Initiation Protocol (SIP)",
draft-tschofenig-sipping-captcha-00 (work in progress),
July 2007.
[I-D.tschofenig-sipping-framework-spit-reduction]
Tschofenig, H., "A Framework for Reducing Spam for
Internet Telephony",
draft-tschofenig-sipping-framework-spit-reduction-00 (work
in progress), June 2007.
[ISO8601] ISO (International Organization for Standardization),
""Data elements and interchange formats -- Information
interchange -- Representation of dates and times", ISO
Standard ISO 8601:2000(E), International Organization for
Standardization, Geneva, Switzerland,", December 2000.
[OMA-TS-XDM_Shared_Policy]
Open Mobile Alliance, "Shared Policy XDM Specification",
2007.
[OTZ] Eggert, P., "Sources for Time Zone and Daylight Saving
Time Data, available at
http://www.twinsun.com/tz/tz-link.htm", 2007.
[RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)",
RFC 2445, November 1998.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language",
RFC 3028, January 2001.
[RFC3266] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6
in Session Description Protocol (SDP)", RFC 3266,
June 2002.
[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
Language (CPL): A Language for User Control of Internet
Telephony Services", RFC 3880, October 2004.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens Networks GmbH & Co KG Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Dan Wing Dan Wing
Cisco Cisco
Phone: Phone:
Email: dwing@cisco.com Email: dwing@cisco.com
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu Email: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Thomas Froment Thomas Froment
Alcatel-Lucent Alcatel-Lucent
1, rue Ampere - BP 80056 1, rue Ampere - BP 80056
Massy, Paris 91302 Massy, Paris 91302
France France
Email: Thomas.Froment@alcatel-lucent.fr Email: Thomas.Froment@alcatel-lucent.fr
Geoffrey Dawirs Geoffrey Dawirs
University of Namur University of Namur
 End of changes. 100 change blocks. 
273 lines changed or deleted 1151 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/