< draft-tschofenig-sipping-framework-spit-reduction-01.txt		draft-tschofenig-sipping-framework-spit-reduction-02.txt >
	Network Working Group H. Tschofenig		SIPPING H. Tschofenig
	Internet-Draft Nokia Siemens Networks		Internet-Draft Nokia Siemens Networks
	Intended status: Informational H. Schulzrinne		Intended status: Informational H. Schulzrinne
	Expires: January 9, 2008 Columbia University		Expires: May 22, 2008 Columbia University
	D. Wing		D. Wing
	J. Rosenberg		J. Rosenberg
	Cisco Systems		Cisco Systems
	D. Schwartz		D. Schwartz
	Kayote Networks		Kayote Networks
	July 8, 2007		November 19, 2007
	A Framework to tackle Spam and Unwanted Communication for Internet		A Framework to tackle Spam and Unwanted Communication for Internet
	Telephony		Telephony
	draft-tschofenig-sipping-framework-spit-reduction-01.txt		draft-tschofenig-sipping-framework-spit-reduction-02.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 41 ¶		skipping to change at page 1, line 41 ¶
	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 9, 2008.		This Internet-Draft will expire on May 22, 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. A number of		might be a problem on SIP open-wide deployed networks. A number of
	solutions have been proposed for dealing with Spam for Internet		solutions have been proposed for dealing with Spam for Internet
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	4. Communication Patterns and User Groups . . . . . . . . . . . . 7		4. Communication Patterns and User Groups . . . . . . . . . . . . 7
	4.1. Closed Groups . . . . . . . . . . . . . . . . . . . . . . 7		4.1. Closed Groups . . . . . . . . . . . . . . . . . . . . . . 7
	4.2. Semi-Open Groups . . . . . . . . . . . . . . . . . . . . . 7		4.2. Semi-Open Groups . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Open Groups . . . . . . . . . . . . . . . . . . . . . . . 8		4.3. Open Groups . . . . . . . . . . . . . . . . . . . . . . . 8
	4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8		4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9		4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9
	5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9		5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10
	5.1. End Host based Rule Enforcement . . . . . . . . . . . . . 9		5.1. End Host based Rule Enforcement . . . . . . . . . . . . . 10
	5.2. Rule Enforcement via a Trusted Intermediary . . . . . . . 10		5.2. Rule Enforcement via a Trusted Intermediary . . . . . . . 10
	5.3. Incremental Deployment . . . . . . . . . . . . . . . . . . 10		5.3. Incremental Deployment . . . . . . . . . . . . . . . . . . 10
	6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12		6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12
	7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 16		10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . . 16		10.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 18		Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
	Intellectual Property and Copyright Statements . . . . . . . . . . 20		Intellectual Property and Copyright Statements . . . . . . . . . . 21
	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 attempts.		a framework for dealing with unwanted communication attempts.
	[I-D.ietf-sipping-spam] provides four core recommendations that need		[I-D.ietf-sipping-spam] provides four core recommendations that need
	to be considered for a SPIT solution, namely		to be considered for a SPIT solution, namely
	skipping to change at page 3, line 25 ¶		skipping to change at page 3, line 25 ¶
	o White Lists		o White Lists
	o Solve the Introduction Problem		o Solve the Introduction Problem
	o Don't Wait Until its Too Late		o Don't Wait Until its Too Late
	This document illustrates how existing building blocks can be put		This document illustrates how existing building blocks can be put
	together to form a solution to deal with SPIT. New building blocks		together to form a solution to deal with SPIT. New building blocks
	can be added to provide more efficient SPIT handling, since there is		can be added to provide more efficient SPIT handling, since there is
	no single solution that provides 100 % protection.		no single solution that provides 100 % protection.
	The main purpose of this document is largely to define a model of		The main purpose of this document is largely to define a model of
	internal device processing, protocol interfaces, and terminology,		internal device processing, protocol interfaces, and terminology to
	which define a way in which we can plug-in future protocols. We		illustrate a way in which SPIT prevention techniques can be added in
	focus only on the most important solution components and consider		a seamless fashion. We focus only on the most important solution
	many other aspects either outside the scope of this work (see		components and consider many other aspects either outside the scope
	Appendix A) and postpone them for future work.		of this work (see Appendix A) and postpone them for future work.
	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].
	3. Framework		3. Framework
	The framework considered in this document assumes that an end user		The framework considered in this document assumes that an end user
	uploads authorization policies to a SIP proxy of its VoIP provider.		uploads authorization policies to a SIP proxy of its VoIP provider.
	That VoIP provider enforces those authorization policies. This		That VoIP provider enforces those authorization policies. This
	separation allows the end user to offload some authorization		separation allows the end user to delegate some authorization
	decisions to the VoIP provider which can save bandwidth and activity		decisions to the VoIP provider.
	on the SIP UA.
	Figure 1 below shows the interaction between the end host and a SIP		Figure 1 below shows the interaction between the end host and a SIP
	proxy belonging to its VoIP provider. The end user, in the role of a		proxy belonging to its VoIP provider. The end user, in the role of a
	recipient for communication attempts, uploads authorization policies.		recipient for communication attempts, may upload authorization
	These policies are processed by corresponding module within the SIP		policies. The entity that writes the rules is referred as Rule
	proxy, called Authorization Engine, that interacts with the message		Maker. The Rule Maker does not necessarily need to be recipient of
	routing functionality. A part of the rule set might, however, also		the communication but it could instead be entity that acts on behalf
	be created automatically as part of interactive interactions (e.g.,		of him or her. Note that a combination is possible as well where
			different entities contribute to the set of rules. These policies
			are processed by corresponding module within the SIP proxy, called
			Authorization Engine, that interacts with the message routing
			functionality. A part of the rule set might, however, also be
			created automatically as part of interactive interactions (e.g.,
	monitoring ongoing communication attempts).		monitoring ongoing communication attempts).
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Authorization |		| Authorization |
	| re-route Policy |		| re-route Policy +------------+ |
	| ^ (implicit) |		| ^ (implicit) ######| Rule Maker | |
	| o +#######+ |		| o +#######+ # +------------+ |
	| o # # |		| o # # # |
	| +---o----------#-------#--+ |		| +---o----------#-------#--+ # Authorization |
	| | o # # | |		| | o # # |<####### Policy |
	+--------+ | | o Proxy # # | |		+--------+ | | o Proxy # # | |
	| | | | o # # |<*******************+ |		| | | | o # # |<*******************+ |
	| Sender |<***>|+-------+ v # | * |		| Sender |<***>|+-------+ v # | * |
	| | | ||Msg. | +-----------+| Authorization * |		| | | ||Msg. | +-----------+| Authorization * |
	+--------+ | ||Routing| | Authz. || Policy (explicit) * |		+--------+ | ||Routing| | Authz. || Policy (explicit) * |
	^ o | ||Engine |<->| Engine |<#################+ * |		^ o | ||Engine |<->| Engine |<#################+ * |
	* o | |+-------+ +-----------+| # * |		* o | |+-------+ +-----------+| # * |
	* o | +-^--*--^-----------------+ # v |		* o | +-^--*--^-----------------+ # v |
	* o | o * o +-------------+ |		* o | o * o +-------------+ |
	* o | o * o | | |		* o | o * o | | |
	* +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient | |		* +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient/ | |
	+**************************************************>| | |		+**************************************************>| Rule Maker | |
	| +-------------+ |		| +-------------+ |
	| |		| |
	| |		| |
	+-------------------Domain Boundary-----------------------+		+-------------------Domain Boundary-----------------------+
	Legend:		Legend:
	oooo: SIP message interaction		oooo: SIP message interaction
	****: Protocol Interaction for authorizing the message sender		****: Protocol Interaction for authorizing the message sender
	####: Management of authorization policies		####: Management of authorization policies
	skipping to change at page 4, line 50 ¶		skipping to change at page 5, line 7 ¶
	Assume that an arbitrary sender transmits a message towards the		Assume that an arbitrary sender transmits a message towards the
	recipients URI that finally hits the SIP proxy on the recipients		recipients URI that finally hits the SIP proxy on the recipients
	side. Information provided within that message are used as input to		side. Information provided within that message are used as input to
	the rule evaluation. Any part of the message may serve as input to		the rule evaluation. Any part of the message may serve as input to
	the evaluation process but for practical reasons only a few selected		the evaluation process but for practical reasons only a few selected
	fields do most of the work. In this document, we argue that the		fields do most of the work. In this document, we argue that the
	authenticated identity of the sender is the most valuable information		authenticated identity of the sender is the most valuable information
	item. In the future, when standardization progresses then, for		item. In the future, when standardization progresses then, for
	example, reputation information obtained from social networks may		example, reputation information obtained from social networks may
	offer additional input to the authorization process. The protocol		offer additional input to the authorization process.
	interaction for authorizing the message sender refers to the ability
	of the recipient or the proxy to interact with the sender to request		The protocol interaction for authorizing the message sender refers to
	authorization. The request for authorization is a pull model whereby		the ability of the recipient or the proxy to interact with the sender
	the proxy or the recipient challenges the sender (e.g., via hash cash		to request authorization. The request for authorization is a pull
	[I-D.jennings-sip-hashcash], or SIP payment		model whereby the proxy or the recipient challenges the sender (e.g.,
			via hash cash [I-D.jennings-sip-hashcash], or SIP payment
	[I-D.jennings-sipping-pay], or Completely Automated Public Turing		[I-D.jennings-sipping-pay], or Completely Automated Public Turing
	Test to Tell Computers and Humans Apart (CAPTCHA) based robot		Test to Tell Computers and Humans Apart (CAPTCHA) based robot
	challenges [I-D.tschofenig-sipping-captcha]) for authorization. SIP		challenges [I-D.tschofenig-sipping-captcha]) for authorization. SIP
	Identity on the other hand realizes as push model whereby		Identity on the other hand realizes as push model whereby
	authentication information is pushed towards the recipient.		authentication information is pushed towards the recipient.
	Figure 2 shows this integration step. The conditions part of the		Figure 2 shows this integration step. The conditions part of the
	rule offer a mechanisms to incrementally extend the overall framework		rule offer a mechanisms to incrementally extend the overall framework
	with new SPIT prevention solution components. Depending on the rule		with new SPIT prevention solution components. Depending on the rule
	evaluation the message may be rerouted to another entity, such as an		evaluation the message may be rerouted to another entity, such as an
	answering machine, to the recipient, rejected or other actions are		answering machine, to the recipient, rejected or other actions are
	triggered. The latter aspect is particularly interesting since it		triggered. The latter aspect is particularly interesting since it
	allows further solution components to be executed. For example, a		allows further solution components to be executed.
	permission request as part of the consent framework.
	SIP msg with		SIP msg with
	authenticated		authenticated
	identity +---------------+		identity +---------------+
	-------------->| |---------------->		-------------->| |---------------->
	Additional | | Spam marked msg		Additional | | Spam marked msg
	Msg fields | Authorization |		Msg fields | Authorization |
	-------------->| Engine |---------------->		-------------->| Engine |---------------->
	Other SPIT | | Re-routed msg		Other SPIT | | Re-routed msg
	Prevention | |		Prevention | |
	skipping to change at page 5, line 48 ¶		skipping to change at page 6, line 5 ¶
	Politely blocked Blocked		Politely blocked Blocked
	Figure 2: Message Filtering and Routing		Figure 2: Message Filtering and Routing
	Note that some traffic analysis and consequently some form of content		Note that some traffic analysis and consequently some form of content
	filtering (e.g., of MESSAGEs) can be applied locally within the VoIP		filtering (e.g., of MESSAGEs) can be applied locally within the VoIP
	provider's domain also under the control of the end user. For		provider's domain also under the control of the end user. For
	example, consider a Voice over IP provider that wants to utilize a		example, consider a Voice over IP provider that wants to utilize a
	statistical analysis tool for Spam prevention. It is not necessary		statistical analysis tool for Spam prevention. It is not necessary
	to standardized the algorithms; the impact for the authorization		to standardized the algorithms; the impact for the authorization
	policies is mainly the ability to allow a Rule Maker to enable or to		policies is mainly the ability to allow the Rule Maker to enable or
	disable the usage of these statistical techniques for SPIT filtering		to disable the usage of these statistical techniques for SPIT
	and potentially to map the output of the analysis process to value		filtering and potentially to map the output of the analysis process
	range from 0 (i.e., the message is not classified as Spam) and 100		to value range from 0 (i.e., the message is not classified as Spam)
	(i.e., the message was classified as Spam). Conveying Spam marking		and 100 (i.e., the message was classified as Spam). Conveying Spam
	is proposed in [I-D.schwartz-sipping-spit-saml] and in		marking is proposed in [I-D.schwartz-sipping-spit-saml], in
	[I-D.niccolini-sipping-feedback-spit]. A Rule Maker may decide to		[I-D.niccolini-sipping-feedback-spit] and in
	act with an appropriate action on such a Spam marking.		[I-D.wing-sipping-spam-score]. A Rule Maker may decide to act with
			an appropriate action on a certain level of Spam marking.
	In a minimalistic SPIT framework only authenticated identities in		In a minimalistic SPIT framework only authenticated identities in
	combination with authorization policies are used. This should serve		combination with authorization policies are used. This should serve
	as a starting point for future work.		as a starting point for future work.
	Authenticated Identities:		Authenticated Identities:
	SIP Identity [RFC4474] is assumed to be used to provide the		SIP Identity [RFC4474] is assumed to be used to provide the
	receiver of a communication attempt with the authenticated		receiver of a communication attempt with the authenticated
	identity. SIP Identity is a reasonable simple specification and		identity. SIP Identity is a reasonable simple specification and
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 45 ¶
	policies do not need to be standardized since they are purely		policies do not need to be standardized since they are purely
	implementation specific details. Even if the authorization		implementation specific details. Even if the authorization
	policies are managed centrally or some amount of policy		policies are managed centrally or some amount of policy
	enforcement is done by trusted intermediaries then still there		enforcement is done by trusted intermediaries then still there
	might not be a need to standardize an authorization policy		might not be a need to standardize an authorization policy
	language if the policies can be modified via a webpage. This type		language if the policies can be modified via a webpage. This type
	of policy handling is done in many cases today already for various		of policy handling is done in many cases today already for various
	applications.		applications.
	Unfortunately, this approach tends to become cumbersome to manage		Unfortunately, this approach tends to become cumbersome to manage
	for end users and therefore it is useful to hide a lot of policy		for end users and therefore it is better to hide a lot of policy
	details from the end user itself and to make use of context		details from the end user itself and to make use of context
	information, for example, address books and authorization policies		information, for example, address books and authorization policies
	available already created for presence based systems.		available already created for presence based systems.
	In some cases the above-described approach is not sufficient		In some cases the above-described approach is not sufficient
	whereby it is necessary to define a standardized protocol, for		whereby it is necessary to define a standardized protocol, for
	example, if policies are used by different entities, created and		example, if policies are used by different entities, created and
	modified in an automatic way and when multiple entities manipulate		modified in an automatic way and when multiple entities manipulate
	policies (potentially on behalf of the person affected by the		policies (potentially on behalf of the person affected by the
	policies), e.g., the user may have multiple devices.		policies), e.g., the user may have multiple devices.
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 29 ¶
	When communication takes place then at least three types of groups		When communication takes place then at least three types of groups
	can be identified.		can be identified.
	4.1. Closed Groups		4.1. Closed Groups
	People in this group communicate only with the peers in their group.		People in this group communicate only with the peers in their group.
	They do not appreciate communication attempts from outside.		They do not appreciate communication attempts from outside.
	Communication is possible only for people within this list. Here is		Communication is possible only for people within this list. Here is
	an example of a closed group: Consider parents that do not want their		an example of a closed group: Consider parents that do not want their
	children from getting contaced by strangers. Hence, they may create		children from getting contacted by strangers. Hence, they may want
	a white list containing the identifies of known friends, parents and		to create a white list containing the identifies of known friends,
	other relatives on behalf of their kids.		parents and other relatives on behalf of their kids.
	The usage of authorization policies for usage with Closed Groups is		The usage of authorization policies for usage with closed groups is
	straight forward.		straight forward. The introduction problem is also not considered
			very large given that the identities are typically known.
	4.2. Semi-Open Groups		4.2. Semi-Open Groups
	In a semi-open environment all members of the same group are allowed		In a semi-open environment all members of the same group are allowed
	to get in contact with everyone else (e.g., for example in a company		to get in contact with everyone else (e.g., for example in a company
	environment). For members outside the company the communication		environment). For members outside the company the communication
	patters depend on the role of the person (e.g., standardization		patters depend on the role of the person (e.g., standardization
	people, sales people, etc.) and on the work style of the person.		people, sales people, etc.) and on the work style of the person.
	For this category we distinguish a number of (non-spam) message		For this category we distinguish a number of (non-spam) message
	skipping to change at page 7, line 45 ¶		skipping to change at page 8, line 4 ¶
	to get in contact with everyone else (e.g., for example in a company		to get in contact with everyone else (e.g., for example in a company
	environment). For members outside the company the communication		environment). For members outside the company the communication
	patters depend on the role of the person (e.g., standardization		patters depend on the role of the person (e.g., standardization
	people, sales people, etc.) and on the work style of the person.		people, sales people, etc.) and on the work style of the person.
	For this category we distinguish a number of (non-spam) message		For this category we distinguish a number of (non-spam) message
	sources based on their characteristics:		sources based on their characteristics:
	o "friends" or "acquaintances", i.e., those we have communicated		o "friends" or "acquaintances", i.e., those we have communicated
	with before.		with before.
	o strangers, divided into 'interesting' and 'uninteresting'. The		o strangers, divided into 'interesting' and 'uninteresting'. The
	latter are messages from people that someone does not care to have		latter are messages from people that someone does not care to have
	a conversation with or respond to, at least at that particular		a conversation with or respond to, at least at that particular
	moment.		moment.
	Strangers can be defined by individual names or whole domains. A		Strangers can be defined by individual names or whole domains. A
	special class of 'stranger' messages are transaction-related		special class of 'stranger' messages are transaction-related
	communications, such as Instant Messaging or automated calls from an		communications, such as Instant Messaging or automated calls from an
	airline or shipping company.		airline or shipping company.
	The usage of authorization policies for usage with Semi-Open Groups		One way to deal with the introduction problem is to make use of
	can be considered manageable.		techniques like hash cash [I-D.jennings-sip-hashcash] or Completely
			Automated Public Turing Test to Tell Computers and Humans Apart
			(CAPTCHA) based robot challenges [I-D.tschofenig-sipping-captcha].
			Alternatively, a communication attempt may also be forwarded to an
			answering maschine or alternative ways of establishing the initial
			interaction may be proposed.
	In the PSTN a certain amount of protection against unwanted calls is		The usage of authorization policies for usage with Semi-Open Groups
	provided due to costs for phone calls. With almost free calls (or		is challenging but is considered manageable.
	instant messages) it might be necessary to abandon the idea of
	allowing end-to-end real-time message delivery in all cases in order
	to avoid the alerting the user.
	4.3. Open Groups		4.3. Open Groups
	People in this type of group are not allowed to limit communication		People in this type of group are not allowed to limit communication
	attempts. Help desks, certain people in governmental agencies,		attempts. Help desks, certain people in governmental agencies,
	banks, insurance companies, etc.		banks, insurance companies, etc.
	For Open Groups the situation is more complicated. Consider a person		For open groups a solution for providing SPIT prevention is far more
	working on a customer support helpdesk. Ideally, they would like to		complicated. Consider a person working on a customer support
	receive only calls from friendly customers (although the motivation		helpdesk. Ideally, they would like to receive only calls from
	for calling is most likely a problem) and the topic of the calls only		friendly customers (although the motivation for calling is most
	relates to problems they are able to solve. Without listening to the		likely a problem) and the topic of the calls only relates to problems
	caller they will have a hard time to know whether the call could be		they are able to solve. Without listening to the caller they will
	classified as SPIT. Many SPIT prevention techniques might not be		have a hard time to know whether the call could be classified as
	applicable since blocking callers is likely not possible and applying		SPIT. Another extreme case is a Public Safety Answering Point where
	other techniques, such as turing tests, might not be ideal in an case		emergency service personell is not allowed to reject calls either.
	of Open Groups.
			Many SPIT prevention techniques might not be applicable since
			blocking callers is likely not possible and applying other
			techniques, such as turing tests, might not be ideal in an case of
			open groups.
			Statistical analysis may be helpful in some cases to deliver
			additional information about the calling party. Social networks
			might provide similar techniques based on reputation based systems.
	4.4. Summary		4.4. Summary
	Based on the discussions regarding communication patters and groups		Based on the discussions regarding communication patters and groups
	the following observations can be made:		the following observations can be made:
	o A single person very likely has many roles and they may have an		o A single person very likely has many roles and they may have an
	impact on the communication patterns.		impact on the communication patterns.
	For example, consider a person who is working in a company but		For example, consider a person who is working in a company but
	also want to be available for family members.		also want to be available for family members.
	skipping to change at page 16, line 4 ¶		skipping to change at page 16, line 32 ¶
	We would like to thank		We would like to thank
	Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva		Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva
	Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for		Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for
	their review comments to a pre-00 version.		their review comments to a pre-00 version.
	Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski,		Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski,
	Saverio Niccolini, Albert Caruana, and Juergen Quittek for their		Saverio Niccolini, Albert Caruana, and Juergen Quittek for their
	comments to the 00 version.		comments to the 00 version.
	10. References		10. References
	10.1. Normative References		10.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", March 1997.		Requirement Levels", March 1997.
	[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.,
	Polk, J., and J. Rosenberg, "Common Policy: A Document		Polk, J., and J. Rosenberg, "Common Policy: A Document
	Format for Expressing Privacy Preferences", RFC 4745,		Format for Expressing Privacy Preferences", RFC 4745,
	February 2007.		February 2007.
	[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)		[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
	Configuration Access Protocol (XCAP)", RFC 4825, May 2007.		Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
	10.2. Informative References		10.2. Informative References
	[I-D.ietf-sipping-spam]		[I-D.ietf-sipping-spam]
	Jennings, C. and J. Rosenberg, "The Session Initiation		Rosenberg, J. and C. Jennings, "The Session Initiation
	Protocol (SIP) and Spam", draft-ietf-sipping-spam-04 (work		Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work
	in progress), February 2007.		in progress), July 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-09 (work in progress),		draft-ietf-simple-presence-rules-10 (work in progress),
	March 2007.		July 2007.
	[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.
			[I-D.wing-sipping-spam-score]
			Wing, D., "Spam Score for SIP",
			draft-wing-sipping-spam-score-00 (work in progress),
			August 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-03 (work
	July 2007.		in progress), November 2007.
	[I-D.ietf-dkim-overview]		[I-D.ietf-dkim-overview]
	Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys		Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys
	Identified Mail (DKIM) Message Signing Service Overview",		Identified Mail (DKIM) Service Overview",
	draft-ietf-dkim-overview-05 (work in progress), June 2007.		draft-ietf-dkim-overview-07 (work in progress),
			November 2007.
	[I-D.tschofenig-sipping-spit-policy]		[I-D.tschofenig-sipping-spit-policy]
	Tschofenig, H., "Anti-SPIT : A Document Format for		Tschofenig, H., "A Document Format for Expressing
	Expressing Anti-SPIT Authorization Policies",		Authorization Policies to tackle Spam and Unwanted
	draft-tschofenig-sipping-spit-policy-00 (work in		Communication for Internet Telephony",
	progress), February 2007.		draft-tschofenig-sipping-spit-policy-01 (work in
			progress), July 2007.
	[I-D.schwartz-sipping-spit-saml]		[I-D.schwartz-sipping-spit-saml]
	Schwartz, D., "SPAM for Internet Telephony (SPIT)		Schwartz, D., "SPAM for Internet Telephony (SPIT)
	Prevention using the Security Assertion Markup Language		Prevention using the Security Assertion Markup Language
	(SAML)", draft-schwartz-sipping-spit-saml-01 (work in		(SAML)", draft-schwartz-sipping-spit-saml-01 (work in
	progress), June 2006.		progress), June 2006.
	[I-D.shacham-http-corr-uris]		[I-D.shacham-http-corr-uris]
	Shacham, R. and H. Schulzrinne, "HTTP Header for Future		Shacham, R. and H. Schulzrinne, "HTTP Header for Future
	Correspondence Addresses", draft-shacham-http-corr-uris-00		Correspondence Addresses", draft-shacham-http-corr-uris-00
	(work in progress), May 2007.		(work in progress), May 2007.
	[I-D.jennings-sipping-pay]		[I-D.jennings-sipping-pay]
	Jennings, C., "Payment for Services in Session Initiation		Jennings, C., "Payment for Services in Session Initiation
	Protocol (SIP)", draft-jennings-sipping-pay-05 (work in		Protocol (SIP)", draft-jennings-sipping-pay-06 (work in
	progress), October 2006.		progress), July 2007.
	[I-D.froment-sipping-spit-requirements]		[I-D.froment-sipping-spit-requirements]
	Froment, T., "Requirements for Authorization Policies to		Froment, T., "Requirements for Authorization Policies to
	tackle Spam for Internet Telephony and Unwanted Traffic",		tackle Spam and Unwanted Communication for Internet
	draft-froment-sipping-spit-requirements-00 (work in		Telephony", draft-froment-sipping-spit-requirements-01
	progress), June 2007.		(work in progress), July 2007.
	[I-D.niccolini-sipping-feedback-spit]		[I-D.niccolini-sipping-feedback-spit]
	Niccolini, S., "SIP Extensions for SPIT identification",		Niccolini, S., "SIP Extensions for SPIT identification",
	draft-niccolini-sipping-feedback-spit-03 (work in		draft-niccolini-sipping-feedback-spit-03 (work in
	progress), February 2007.		progress), February 2007.
	[I-D.tschofenig-sipping-captcha]		[I-D.tschofenig-sipping-captcha]
	Tschofenig, H. and E. Leppanen, "Completely Automated		Tschofenig, H. and E. Leppanen, "Completely Automated
	Public Turing Test to Tell Computers and Humans Apart		Public Turing Test to Tell Computers and Humans Apart
	(CAPTCHA) based Robot Challenges for the Session		(CAPTCHA) based Robot Challenges for the Session
	Initiation Protocol (SIP)", July 2007.		Initiation Protocol (SIP)",
			draft-tschofenig-sipping-captcha-00 (work in progress),
			July 2007.
	[Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt,		[Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt,
	C., and H. Waack, "Developing a Legally Compliant		C., and H. Waack, "Developing a Legally Compliant
	Reachability Management System as a Countermeasure against		Reachability Management System as a Countermeasure against
	SPIT, Third Annual VoIP Security Workshop, Berlin,		SPIT, Third Annual VoIP Security Workshop, Berlin,
	available at		available at
	https://tepin.aiki.de/blog/uploads/spit-al.pdf",		https://tepin.aiki.de/blog/uploads/spit-al.pdf",
	June 2006.		June 2006.
	[Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen		[Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen
End of changes. 34 change blocks.
	96 lines changed or deleted		123 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/