< draft-froment-sipping-spit-requirements-01.txt		draft-froment-sipping-spit-requirements-02.txt >
	SIPPING H. Tschofenig, Ed.		SIPPING H. Tschofenig, Ed.
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Informational G. Dawirs		Intended status: Informational G. Dawirs
	Expires: January 10, 2008 University of Namur		Expires: August 28, 2008 University of Namur
	T. Froment		T. Froment
	Alcatel-Lucent		Alcatel-Lucent
	D. Wing		D. Wing
	Cisco		Cisco
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	July 9, 2007		February 25, 2008
	Requirements for Authorization Policies to tackle Spam and Unwanted		Requirements for Authorization Policies to tackle Spam and Unwanted
	Communication for Internet Telephony		Communication for Internet Telephony
	draft-froment-sipping-spit-requirements-01.txt		draft-froment-sipping-spit-requirements-02
	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 January 10, 2008.		This Internet-Draft will expire on August 28, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	Abstract		Abstract
	Spam over Internet Telephony (SPIT) is one of the foreseen future		Spam over Internet Telephony (SPIT) is one of the foreseen future
	forms of spamming that SIP open-wide networks may have to handle.		forms of spamming that SIP open-wide networks may have to handle.
	SPIT also has more impact on users than email spam since it is more		SPIT also has more impact on users than email spam since it is more
	intrusive. Email as a store-and-forward communication mechanism		intrusive. Email as a store-and-forward communication mechanism
	allows for several filtering mechanisms to be applied to the full		allows for several filtering mechanisms to be applied to the full
	content before being presented to the user. Session Initiation		content before being presented to the user. Session Initiation
	Protocol (SIP) interaction is, in contrast, real-time communication		Protocol (SIP) interaction is, in contrast, real-time communication
	and therefore does not provide much information prior to the		and therefore does not provide much information prior to the
	transmission of the content, making it both harder to filter and more		transmission of the content, making it both harder to filter and more
	annoying to users. The responsibility for filtering, blocking calls,		annoying to users. The responsibility for filtering, blocking calls,
	or taking any other preventive action can belong to different		or taking any other preventive action can belong to different
	elements in the call flow and may depend on various factors.		elements in the call flow and may depend on various factors. This
			document discusses the requirements to define authorization policies
	This document discusses the requirements to define authorization		that should allow end users or other parties to setup anti-SPIT
	policies that should allow end users or other parties to setup anti-		policies for triggering these actions. These policies typically
	SPIT policies for triggering these actions. These policies typically
	match a particular SIP communication pattern based on a number of		match a particular SIP communication pattern based on a number of
	attributes. The range of attributes includes information provided,		attributes. The range of attributes includes information provided,
	for example, by the SIP protocol itself, by the SIP identity		for example, by the SIP protocol itself, by the SIP identity
	mechanism, by information carried within SAML assertions, reputation		mechanism, by information carried within SAML assertions, reputation
	systems of social networks and other extensions.		systems of social networks or other extensions.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3. Transformations . . . . . . . . . . . . . . . . . . . . . 8		3.3. Transformations . . . . . . . . . . . . . . . . . . . . . 8
	3.4. Generic Requirements . . . . . . . . . . . . . . . . . . . 8		3.4. Generic Requirements . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 4, line 7 ¶		skipping to change at page 4, line 7 ¶
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 10		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 12		7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
	7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 12		7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 12
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
	Intellectual Property and Copyright Statements . . . . . . . . . . 15		Intellectual Property and Copyright Statements . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The problem of SPIT is an important challenge and it appears that a		The problem of SPIT is an important challenge and it is to expect
	combination of several techniques is desirable to provide a framework		that a combination of several techniques is desirable to provide a
	to deal with it.		framework to deal with it. The goal of SPIT-policies is not to
			discuss these techniques, or to propose new ones. It just suggest to
			provide a way to define these policies using a standardized XML
			format.
	One important building block is to provide a mechanism to instruct a		One important building block is to provide a mechanism to instruct a
	trusted SIP proxy or any other SIP element to influence message		trusted SIP proxy or any other SIP element to influence message
	handling of incoming requests according to policies. Different		handling of incoming requests according to policies. Different
	entities, such as end users, parents on behalf of their kids or		entities, such as end users, parents on behalf of their kids or
	system administrators, might create and modify authorization		system administrators, might create, modify or delete authorization
	policies.		policies.
	Some attributes in an incoming message play a more important role		Some attributes in an incoming message play a more important role
	than others. For example, applying authorization policies based on		than others. For example, applying authorization policies based on
	the authenticated identity, see [RFC4474], is an effective way to		the authenticated identity, see [RFC4474], is an effective way to
	make decisions regarding unwanted traffic in many cases.		make decisions regarding unwanted traffic in many cases.
	This document identifies requirements for authorization policies when		This document identifies requirements for authorization policies when
	used to influence message handling for unwanted communicaion		used to influence message handling for unwanted communication
	attempts.		attempts.
	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 [RFC2119],		document are to be interpreted as described in RFC 2119 [RFC2119],
	with the important qualification that, unless otherwise stated, these		with the important qualification that, unless otherwise stated, these
	terms apply to the design of the authorization policies, not its		terms apply to the design of the authorization policies, not its
	implementation or application.		implementation or application.
	skipping to change at page 6, line 37 ¶		skipping to change at page 6, line 37 ¶
	Req-C 5: Policies SHOULD allow an anonymous identity as a condition.		Req-C 5: Policies SHOULD allow an anonymous identity as a condition.
	Message handling might be different depending on the content of the		Message handling might be different depending on the content of the
	SIP message header fields.		SIP message header fields.
	Req-C 6: Policies SHOULD allow conditions to refer to the		Req-C 6: Policies SHOULD allow conditions to refer to the
	"destination" (which corresponds to the "Request-URI") and		"destination" (which corresponds to the "Request-URI") and
	"original-destination" (which corresponds to the "To" header).		"original-destination" (which corresponds to the "To" header).
	Req-C 7: Policies SHOULD allow conditions to refer to the method		Req-C 7: Policies SHOULD allow conditions to refer to the method
	invoked by the caller (e.g., INVITE, REFER, MESSAGE).		invoked by the caller (e.g., INVITE, REFER, MESSAGE,
			SUBSCRIBE).
	Motivation: Some SIP methods are more intrusive than others		Motivation: Some SIP methods are more intrusive than others
	(the default applicative behaviour when SIP MESSAGEs are		(the default applicative behaviour when SIP MESSAGEs are
	received is often to pop-up the message on the UAS side),		received is often to pop-up the message on the UAS side),
	adopting a different filtering policy depending of the method		adopting a different filtering policy depending of the method
	invoked will enhance the user's protection.		invoked will enhance the user's protection.
	Req-C 8: Policies SHOULD allow the entity that writes the rules to		Req-C 8: Policies SHOULD allow the entity that writes the rules to
	take actions on messages that are marked as Spam.		take actions on messages that are marked as Spam.
	Note that such a condition element should be seen in		Note that such a condition element should be seen in
	context of the authenticated domain or or otherwise		context of the authenticated domain or, otherwise, of a
	protected information to avoid security		protected information to avoid security
	vulnerabilities.		vulnerabilities.
	Req-C 9: Policies MAY allow to make decisions based on the current		Req-C 9: Policies MAY allow to make decisions based on the current
	state of the user. E.g., based on a user selected active		state of the user. E.g., based on a user who selected an
	profile, or sphere or other presence information.		active profile, or sphere or another presence information.
	Req-C 10: Policies SHOULD support consitions based on the content		Req-C 10: Policies SHOULD support consitions based on the content
	type and/or offered (or used) media of a message.		type and/or offered (or used) media of a message.
	Message handling might be different based on time.		Message handling might be different based on time/date.
	Req-C 11: Policies SHOULD allow conditions that refer to the		Req-C 11: Policies SHOULD allow conditions that refer to the
	reception date, time, timezone or period of time of the		reception date, time, timezone or period of time of the
	incoming request.		incoming request.
	Message handling might be different based on the language.		Message handling might be different based on the language.
	Req-C 12: Policies SHOULD allow to make decisions based on the		Req-C 12: Policies SHOULD allow to make decisions based on the
	languages in which the originator of the call wishes to		languages in which the originator of the call wishes to
	communicate.		communicate.
	3.2. Actions		3.2. Actions
	Req-A 1: Policies SHOULD allow messages to get "blocked", i.e., to		Req-A 1: Policies SHOULD allow messages to get "blocked", i.e., to
	stop forwarding the request and to return an answer with a		stop forwarding the request and to return an answer with a
	``403 Forbidden''		"403 Forbidden''
	Req-A 2: Policies SHOULD allow messages to get "politely blocked",		Req-A 2: Policies SHOULD allow messages to get "politely blocked",
	i.e., to drop the request without returning an answer.		i.e., to drop the request without returning any answer.
	Req-A 3: Policies SHOULD allow messages to get "marked", i.e., to		Req-A 3: Policies SHOULD allow messages to get "marked", i.e., to
	forward the request and mark it as "potential Spam" for		forward the request and mark it as "potential Spam" for
	filtering at the end point or at subsequent entities along the		filtering at the end point or at subsequent entities along the
	signaling path.		signaling path.
	Req-A 4: Policies SHOULD allow messages to be "allowed", i.e., to		Req-A 4: Policies SHOULD allow messages to be "allowed", i.e., to
	forward this message.		forward this message.
	Req-A 5: Policies MUST allow messages to be "redirected" to, for		Req-A 5: Policies MUST allow messages to be "redirected" to, for
	skipping to change at page 8, line 9 ¶		skipping to change at page 8, line 9 ¶
	[I-D.jennings-sip-hashcash] or the consent framework"		[I-D.jennings-sip-hashcash] or the consent framework"
	[I-D.ietf-sip-consent-framework]. A specification developing		[I-D.ietf-sip-consent-framework]. A specification developing
	a SPIT prevention mechanism should provide information on how		a SPIT prevention mechanism should provide information on how
	they can be incorporated into the authorization policy		they can be incorporated into the authorization policy
	framework.		framework.
	Req-A 7: Policies MAY allow an e-mail (or SMS, MMS) or other		Req-A 7: Policies MAY allow an e-mail (or SMS, MMS) or other
	notifications to be sent to the user about the actions taken		notifications to be sent to the user about the actions taken
	due to a specific call attempt.		due to a specific call attempt.
			R8: Policies MAY allow the usage of one or many feedback
			mechanisms.
	3.3. Transformations		3.3. Transformations
	Req-T 1: Policies SHOULD allow SIP messages to be marked with a		Req-T 1: Policies SHOULD allow SIP messages to be marked with a
	certain SPIT probability in case SPIT detection and policy		certain SPIT probability in case SPIT detection and policy
	enforcement is excecuted on different entities. For example,		enforcement is excecuted on different entities. For example,
	a network element might run a statistical SPIT detection tool		a network element might run a statistical SPIT detection tool
	but the authorization policies are executed on a different		but the authorization policies are executed on a different
	entity, such as the end host. Note that it needs to be		entity, such as the end host. Note that it needs to be
	ensured that an adversary is not able to set the SPIT		ensured that an adversary is not able to set the SPIT
	probabity values since otherwise the authorization policies		probabity values since otherwise the authorization policies
	skipping to change at page 12, line 16 ¶		skipping to change at page 12, line 16 ¶
	7.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	7.2. References		7.2. References
	[I-D.ietf-sieve-3028bis]		[I-D.ietf-sieve-3028bis]
	Showalter, T. and P. Guenther, "Sieve: An Email Filtering		Showalter, T. and P. Guenther, "Sieve: An Email Filtering
	Language", draft-ietf-sieve-3028bis-12 (work in progress),		Language", draft-ietf-sieve-3028bis-13 (work in progress),
	February 2007.		October 2007.
	[I-D.ietf-simple-presence-rules]		[I-D.ietf-simple-presence-rules]
	Rosenberg, J., "Presence Authorization Rules",		Rosenberg, J., "Presence Authorization Rules",
	draft-ietf-simple-presence-rules-10 (work in progress),		draft-ietf-simple-presence-rules-10 (work in progress),
	July 2007.		July 2007.
	[I-D.ietf-sip-consent-framework]		[I-D.ietf-sip-consent-framework]
	Rosenberg, J., "A Framework for Consent-Based		Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
	Communications in the Session Initiation Protocol (SIP)",		for Consent-based Communications in the Session Initiation
	draft-ietf-sip-consent-framework-02 (work in progress),		Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work
	July 2007.		in progress), January 2008.
	[I-D.jennings-sip-hashcash]		[I-D.jennings-sip-hashcash]
	Jennings, C., "Computational Puzzles for SPAM Reduction in		Jennings, C., "Computational Puzzles for SPAM Reduction in
	SIP", draft-jennings-sip-hashcash-05 (work in progress),		SIP", draft-jennings-sip-hashcash-06 (work in progress),
	June 2007.		July 2007.
	[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing		[RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing
	Language (CPL): A Language for User Control of Internet		Language (CPL): A Language for User Control of Internet
	Telephony Services", RFC 3880, October 2004.		Telephony Services", RFC 3880, October 2004.
	[RFC4474] Peterson, J. and C. Jennings, "Enhancements for		[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
	Authenticated Identity Management in the Session		Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 4474, August 2006.		Initiation Protocol (SIP)", RFC 4474, August 2006.
	[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,		[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	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@cs.columbia.edu		Email: hgs@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 21 change blocks.
	32 lines changed or deleted		38 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/