idnits 2.17.00 (12 Aug 2021) /tmp/idnits9703/draft-tschofenig-sipping-framework-spit-reduction-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 900. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 906. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 19, 2007) is 5296 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sip-consent-framework' is defined on line 736, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: draft-ietf-sipping-spam has been published as RFC 5039 == Outdated reference: draft-ietf-simple-presence-rules has been published as RFC 5025 == Outdated reference: A later version (-02) exists of draft-wing-sipping-spam-score-00 == Outdated reference: draft-ietf-sip-consent-framework has been published as RFC 5360 == Outdated reference: draft-ietf-dkim-overview has been published as RFC 5585 == Outdated reference: A later version (-03) exists of draft-tschofenig-sipping-spit-policy-01 == Outdated reference: A later version (-03) exists of draft-froment-sipping-spit-requirements-01 == Outdated reference: A later version (-01) exists of draft-tschofenig-sipping-captcha-00 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational H. Schulzrinne 5 Expires: May 22, 2008 Columbia University 6 D. Wing 7 J. Rosenberg 8 Cisco Systems 9 D. Schwartz 10 Kayote Networks 11 November 19, 2007 13 A Framework to tackle Spam and Unwanted Communication for Internet 14 Telephony 15 draft-tschofenig-sipping-framework-spit-reduction-02.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on May 22, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 Spam, defined as sending unsolicited messages to someone in bulk, 49 might be a problem on SIP open-wide deployed networks. A number of 50 solutions have been proposed for dealing with Spam for Internet 51 Telephony (SPIT), for example, content filtering, black lists, white 52 lists, consent-based communication, reputation systems, address 53 obfuscation, limited use addresses, turing tests, computational 54 puzzles, payments at risk, circles of trust, and many others. This 55 document describes the big picture that illustrates how the different 56 building blocks fit together and can be deployed incrementally. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 4. Communication Patterns and User Groups . . . . . . . . . . . . 7 64 4.1. Closed Groups . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. Semi-Open Groups . . . . . . . . . . . . . . . . . . . . . 7 66 4.3. Open Groups . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 10 70 5.1. End Host based Rule Enforcement . . . . . . . . . . . . . 10 71 5.2. Rule Enforcement via a Trusted Intermediary . . . . . . . 10 72 5.3. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 73 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 74 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 80 Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 19 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 82 Intellectual Property and Copyright Statements . . . . . . . . . . 21 84 1. Introduction 86 The problem of Spam for Internet Telephony (SPIT) is an imminent 87 challenge and only the combination of several techniques can provide 88 a framework for dealing with unwanted communication attempts. 90 [I-D.ietf-sipping-spam] provides four core recommendations that need 91 to be considered for a SPIT solution, namely 93 o Strong Identity 94 o White Lists 95 o Solve the Introduction Problem 96 o Don't Wait Until its Too Late 98 This document illustrates how existing building blocks can be put 99 together to form a solution to deal with SPIT. New building blocks 100 can be added to provide more efficient SPIT handling, since there is 101 no single solution that provides 100 % protection. 103 The main purpose of this document is largely to define a model of 104 internal device processing, protocol interfaces, and terminology to 105 illustrate a way in which SPIT prevention techniques can be added in 106 a seamless fashion. We focus only on the most important solution 107 components and consider many other aspects either outside the scope 108 of this work (see Appendix A) and postpone them for future work. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in RFC 2119 [RFC2119]. 116 3. Framework 118 The framework considered in this document assumes that an end user 119 uploads authorization policies to a SIP proxy of its VoIP provider. 120 That VoIP provider enforces those authorization policies. This 121 separation allows the end user to delegate some authorization 122 decisions to the VoIP provider. 124 Figure 1 below shows the interaction between the end host and a SIP 125 proxy belonging to its VoIP provider. The end user, in the role of a 126 recipient for communication attempts, may upload authorization 127 policies. The entity that writes the rules is referred as Rule 128 Maker. The Rule Maker does not necessarily need to be recipient of 129 the communication but it could instead be entity that acts on behalf 130 of him or her. Note that a combination is possible as well where 131 different entities contribute to the set of rules. These policies 132 are processed by corresponding module within the SIP proxy, called 133 Authorization Engine, that interacts with the message routing 134 functionality. A part of the rule set might, however, also be 135 created automatically as part of interactive interactions (e.g., 136 monitoring ongoing communication attempts). 138 +---------------------------------------------------------+ 139 | Authorization | 140 | re-route Policy +------------+ | 141 | ^ (implicit) ######| Rule Maker | | 142 | o +#######+ # +------------+ | 143 | o # # # | 144 | +---o----------#-------#--+ # Authorization | 145 | | o # # |<####### Policy | 146 +--------+ | | o Proxy # # | | 147 | | | | o # # |<*******************+ | 148 | Sender |<***>|+-------+ v # | * | 149 | | | ||Msg. | +-----------+| Authorization * | 150 +--------+ | ||Routing| | Authz. || Policy (explicit) * | 151 ^ o | ||Engine |<->| Engine |<#################+ * | 152 * o | |+-------+ +-----------+| # * | 153 * o | +-^--*--^-----------------+ # v | 154 * o | o * o +-------------+ | 155 * o | o * o | | | 156 * +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient/ | | 157 +**************************************************>| Rule Maker | | 158 | +-------------+ | 159 | | 160 | | 161 +-------------------Domain Boundary-----------------------+ 163 Legend: 165 oooo: SIP message interaction 166 ****: Protocol Interaction for authorizing the message sender 167 ####: Management of authorization policies 169 Figure 1: Overview 171 Assume that an arbitrary sender transmits a message towards the 172 recipients URI that finally hits the SIP proxy on the recipients 173 side. Information provided within that message are used as input to 174 the rule evaluation. Any part of the message may serve as input to 175 the evaluation process but for practical reasons only a few selected 176 fields do most of the work. In this document, we argue that the 177 authenticated identity of the sender is the most valuable information 178 item. In the future, when standardization progresses then, for 179 example, reputation information obtained from social networks may 180 offer additional input to the authorization process. 182 The protocol interaction for authorizing the message sender refers to 183 the ability of the recipient or the proxy to interact with the sender 184 to request authorization. The request for authorization is a pull 185 model whereby the proxy or the recipient challenges the sender (e.g., 186 via hash cash [I-D.jennings-sip-hashcash], or SIP payment 187 [I-D.jennings-sipping-pay], or Completely Automated Public Turing 188 Test to Tell Computers and Humans Apart (CAPTCHA) based robot 189 challenges [I-D.tschofenig-sipping-captcha]) for authorization. SIP 190 Identity on the other hand realizes as push model whereby 191 authentication information is pushed towards the recipient. 193 Figure 2 shows this integration step. The conditions part of the 194 rule offer a mechanisms to incrementally extend the overall framework 195 with new SPIT prevention solution components. Depending on the rule 196 evaluation the message may be rerouted to another entity, such as an 197 answering machine, to the recipient, rejected or other actions are 198 triggered. The latter aspect is particularly interesting since it 199 allows further solution components to be executed. 201 SIP msg with 202 authenticated 203 identity +---------------+ 204 -------------->| |----------------> 205 Additional | | Spam marked msg 206 Msg fields | Authorization | 207 -------------->| Engine |----------------> 208 Other SPIT | | Re-routed msg 209 Prevention | | 210 Components | |----------------> 211 -------------->+---------------+ Forwarded to 212 | | original recipient 213 | | 214 <-----------+ +----------->|| 215 Politely blocked Blocked 217 Figure 2: Message Filtering and Routing 219 Note that some traffic analysis and consequently some form of content 220 filtering (e.g., of MESSAGEs) can be applied locally within the VoIP 221 provider's domain also under the control of the end user. For 222 example, consider a Voice over IP provider that wants to utilize a 223 statistical analysis tool for Spam prevention. It is not necessary 224 to standardized the algorithms; the impact for the authorization 225 policies is mainly the ability to allow the Rule Maker to enable or 226 to disable the usage of these statistical techniques for SPIT 227 filtering and potentially to map the output of the analysis process 228 to value range from 0 (i.e., the message is not classified as Spam) 229 and 100 (i.e., the message was classified as Spam). Conveying Spam 230 marking is proposed in [I-D.schwartz-sipping-spit-saml], in 231 [I-D.niccolini-sipping-feedback-spit] and in 232 [I-D.wing-sipping-spam-score]. A Rule Maker may decide to act with 233 an appropriate action on a certain level of Spam marking. 235 In a minimalistic SPIT framework only authenticated identities in 236 combination with authorization policies are used. This should serve 237 as a starting point for future work. 239 Authenticated Identities: 241 SIP Identity [RFC4474] is assumed to be used to provide the 242 receiver of a communication attempt with the authenticated 243 identity. SIP Identity is a reasonable simple specification and 244 does not rely on a huge amount of infrastructure support. 246 Note: SIP Identity is comparable to DomainKeys Identified Mail 247 (DKIM) [I-D.ietf-dkim-overview] used for associating a 248 "responsible" identity with an email message and provides a 249 means of verifying that the association is legitimate. 251 Authorization Policies: 253 When the white lists are stored and managed only at the end host 254 then the authorization policies and the protocol to modify the 255 policies do not need to be standardized since they are purely 256 implementation specific details. Even if the authorization 257 policies are managed centrally or some amount of policy 258 enforcement is done by trusted intermediaries then still there 259 might not be a need to standardize an authorization policy 260 language if the policies can be modified via a webpage. This type 261 of policy handling is done in many cases today already for various 262 applications. 264 Unfortunately, this approach tends to become cumbersome to manage 265 for end users and therefore it is better to hide a lot of policy 266 details from the end user itself and to make use of context 267 information, for example, address books and authorization policies 268 available already created for presence based systems. 270 In some cases the above-described approach is not sufficient 271 whereby it is necessary to define a standardized protocol, for 272 example, if policies are used by different entities, created and 273 modified in an automatic way and when multiple entities manipulate 274 policies (potentially on behalf of the person affected by the 275 policies), e.g., the user may have multiple devices. 277 An example solution for authorization policies providing Spam 278 prevention capabilities are described in 279 [I-D.tschofenig-sipping-spit-policy] with the requirements 280 detailed in [I-D.froment-sipping-spit-requirements]. 282 The white list needs to be created somehow and hence there is an 283 introduction problem. Section 4 discusses this aspect in more 284 details. 286 4. Communication Patterns and User Groups 288 When communication takes place then at least three types of groups 289 can be identified. 291 4.1. Closed Groups 293 People in this group communicate only with the peers in their group. 294 They do not appreciate communication attempts from outside. 295 Communication is possible only for people within this list. Here is 296 an example of a closed group: Consider parents that do not want their 297 children from getting contacted by strangers. Hence, they may want 298 to create a white list containing the identifies of known friends, 299 parents and other relatives on behalf of their kids. 301 The usage of authorization policies for usage with closed groups is 302 straight forward. The introduction problem is also not considered 303 very large given that the identities are typically known. 305 4.2. Semi-Open Groups 307 In a semi-open environment all members of the same group are allowed 308 to get in contact with everyone else (e.g., for example in a company 309 environment). For members outside the company the communication 310 patters depend on the role of the person (e.g., standardization 311 people, sales people, etc.) and on the work style of the person. 313 For this category we distinguish a number of (non-spam) message 314 sources based on their characteristics: 316 o "friends" or "acquaintances", i.e., those we have communicated 317 with before. 319 o strangers, divided into 'interesting' and 'uninteresting'. The 320 latter are messages from people that someone does not care to have 321 a conversation with or respond to, at least at that particular 322 moment. 324 Strangers can be defined by individual names or whole domains. A 325 special class of 'stranger' messages are transaction-related 326 communications, such as Instant Messaging or automated calls from an 327 airline or shipping company. 329 One way to deal with the introduction problem is to make use of 330 techniques like hash cash [I-D.jennings-sip-hashcash] or Completely 331 Automated Public Turing Test to Tell Computers and Humans Apart 332 (CAPTCHA) based robot challenges [I-D.tschofenig-sipping-captcha]. 333 Alternatively, a communication attempt may also be forwarded to an 334 answering maschine or alternative ways of establishing the initial 335 interaction may be proposed. 337 The usage of authorization policies for usage with Semi-Open Groups 338 is challenging but is considered manageable. 340 4.3. Open Groups 342 People in this type of group are not allowed to limit communication 343 attempts. Help desks, certain people in governmental agencies, 344 banks, insurance companies, etc. 346 For open groups a solution for providing SPIT prevention is far more 347 complicated. Consider a person working on a customer support 348 helpdesk. Ideally, they would like to receive only calls from 349 friendly customers (although the motivation for calling is most 350 likely a problem) and the topic of the calls only relates to problems 351 they are able to solve. Without listening to the caller they will 352 have a hard time to know whether the call could be classified as 353 SPIT. Another extreme case is a Public Safety Answering Point where 354 emergency service personell is not allowed to reject calls either. 356 Many SPIT prevention techniques might not be applicable since 357 blocking callers is likely not possible and applying other 358 techniques, such as turing tests, might not be ideal in an case of 359 open groups. 361 Statistical analysis may be helpful in some cases to deliver 362 additional information about the calling party. Social networks 363 might provide similar techniques based on reputation based systems. 365 4.4. Summary 367 Based on the discussions regarding communication patters and groups 368 the following observations can be made: 370 o A single person very likely has many roles and they may have an 371 impact on the communication patterns. 372 For example, consider a person who is working in a company but 373 also want to be available for family members. 374 o The context in which a person is may change at any time. For 375 example, a person might be available for family members while at 376 work except during an important meeting where communication 377 attempts may be rejected. Switching a context has an impact for 378 reachability and the means for communicating with a specific 379 recipient, based on enabled rule sets. 381 From an authorization policy point of view it is important to be able 382 to express a sphere, i.e., the state a user is in and to switch 383 between different spheres easily by thereby switching to a different 384 rule set. 386 4.5. Usability 388 An important aspect in the usage of authorization policies is to 389 assist the user when creating policies. Ideally, the policies should 390 be established automatically. Below, there are a couple of examples 391 to illustrate the idea given that these aspects are largely 392 implementation issues: 394 o It must be possible for the proxy to automatically add addresses 395 on outbound messages and calls to the rule set. This approach is 396 similar to stateful packet filtering firewalls where outbound 397 packets establish state at the firewall to allow inbound packets 398 to traverse it again. 399 o Already available information in the address book can be used for 400 building the policy rules there is quite likely already a 401 relationship available with these persons existent. 402 o A large amount of email is non-personal, automated communication, 403 such as newsletters, confirmations and legitimate advertisements. 404 These are often tagged as spam by content filters. This type of 405 correspondence is usually initiated by a transaction over the web, 406 such as a purchase or signing up for a service. 407 [I-D.shacham-http-corr-uris], for example, defines an HTTP header 408 for conveying future correspondence addresses that can be 409 integrated in the rule set. 411 5. Protocol Interactions 413 This section describes the necessary building blocks that are 414 necessary to tie the framework together. We will describe two 415 different environments, namely one where rule enforcement happens at 416 the end host and another one where a trusted network intermediary 417 performs the actions. 419 5.1. End Host based Rule Enforcement 421 o SIP Identity [RFC4474] is mandatory to implement at the end host 422 and used to determine the authenticated identity of the sending 423 side. 424 o Authorization policies are purely implementation specific matter. 426 Since a purely end host based rule enforcement suffers from a number 427 of drawbacks, rule enforcement by a trusted intermediary is also 428 offered. 430 5.2. Rule Enforcement via a Trusted Intermediary 432 o SIP Identity [RFC4474] or a corresponding mechanism is mandatory 433 to implement at the trusted intermediary (e.g., the immediate VoIP 434 provider) and it determines the authenticated identity of the 435 sending side. 436 o Authorization Policies based on the Common Policy framework 437 [RFC4745], as extended in [I-D.tschofenig-sipping-spit-policy] for 438 the purpose of SPIT prevention, are mandatory to implement at the 439 end host side and at the trusted intermediary. The implementation 440 of the rule evaluation engine might only be necessary on the 441 trusted VoIP proxy. Harmonization with the work done for presence 442 authorization [I-D.ietf-simple-presence-rules], which is based on 443 Common Policy [RFC4745], can be accomplished and is highly 444 desirable. 445 o XML Configuration Access Protocol (XCAP) [RFC4825] is used to 446 create, modify and delete authorization policies and is mandatory 447 to implement at the end host side and at the trusted intermediary. 449 5.3. Incremental Deployment 451 An important property is incremental deployment of additional 452 solution components that can be added and used when they become 453 available. This section aims to illustrate how the extensibility is 454 accomplished, based on an example. 456 Consider a VoIP provider that provides authorization policies that 457 provide the following functionality equivalent to the Common Policy 458 framework, i.e., identity-based, sphere and validity based conditions 459 initially. For actions only 'redirection' and 'blocking' is 460 provided. In our example we give this basic functionality the AUID 461 'new-spit-policy-example' with the namespace 462 'urn:ietf:params:xml:ns:new-spit-policy-example'. 464 When a client queries the capabilities of a SIP proxy in the VoIP 465 providers network using XCAP the following exchange may take place. 467 GET /xcap-caps/global/index HTTP/1.1 468 Host: xcap.example.com 470 Initial XCAP Query for Capabilities 472 HTTP/1.1 200 OK 473 Etag: "wwhha" 474 Content-Type: application/xcap-caps+xml 476 477 478 479 new-spit-policy-example 480 xcap-caps 481 482 483 urn:ietf:params:xml:ns:xcap-caps 484 urn:ietf:params:xml:ns:spit-policy 485 urn:ietf:params:xml:ns:common-policy 486 487 489 Initial XCAP Response with the supported Capabilities 491 As shown in the example above, Common Policy and the example SPIT 492 extension is implemented and the client can upload rules according to 493 the definition of the rule set functionality. 495 Later, when the VoIP provider updates the functionality of 496 authorization policies as more sophisticated mechanisms become 497 available and get implemented the functionality of the authorization 498 policy engine is enhanced with, for example, hashcash and the ability 499 to perform statistical analysis of signaling message. The latter 500 functionality comes with the ability to mark messages are Spam and 501 the ability for end users to enable/disable this functionality. We 502 use the namespaces 'urn:ietf:params:xml:ns:hashcash' and 503 'urn:ietf:params:xml:ns:statistical-analysis' for those. 505 A end user could now make use of these new functions and a capability 506 query of the SIP proxy would provide the following response. 508 GET /xcap-caps/global/index HTTP/1.1 509 Host: xcap.example.com 511 Second XCAP Query for Capabilities 513 HTTP/1.1 200 OK 514 Etag: "wwhha" 515 Content-Type: application/xcap-caps+xml 517 518 519 520 spit-policy 521 xcap-caps 522 hashcash 523 statistical-analysis 524 525 526 urn:ietf:params:xml:ns:spit-policy 527 urn:ietf:params:xml:ns:common-policy 528 urn:ietf:params:xml:ns:hashcash 529 urn:ietf:params:xml:ns:statistical-analysis 530 531 533 Second XCAP Response with the supported Capabilities 535 New SPIT handling functionality may extend condition, actions and/or 536 transformation elements of a rule. 538 6. Privacy Considerations 540 This document does not propose to distribute the user's authorization 541 policies to other VoIP providers nor is the configuration of policies 542 at SIP proxies other than the trusted user's VoIP provider necessary. 543 Furthemore, if blocking or influencing of the message processing is 544 executed by the VoIP provider then they have to be explicitly enabled 545 by the end user. Blocking of messages, even if it is based on 546 "super-clever" machine learning techniques often introduces 547 unpredictability. 549 Legal norms from fields of law can take regulative effects in the 550 context of SPIT processing, such as constitutional law, data 551 protection law, telecommunication law, teleservices law, criminal 552 law, and possibly administrative law. See, for example, [Law1], 553 [Law2] and [Law3]. For example, it is mandatory to pass full control 554 of SPIT filtering to the end user, as this minimises legal problems. 556 An overview about regulatory aspects can be found in [Spit-AL]. 558 7. Example 560 This section shows an example whereby we consider a user 561 Bob@company-example.com that writes (most likely via a nice user 562 interface) the following policies. We use a high-level language to 563 show the main idea of the policies. 565 RULE 1: 566 IF identity=alice@foo.example.com THEN ACCEPT 567 IF identity=tony@bar.example.com THEN ACCEPT 569 RULE 2: 570 IF domain=company-example.com THEN ACCEPT 572 RULE 3: 573 IF unauthenticated THEN 574 EXECUTE hashcash 576 RULE 4: 577 IF 578 THEN 579 REDIRECT sip:voicebox@company-example.com 581 RULE 5: 582 IF 583 THEN 584 block 586 Example of Bob's Rule Set 588 At some point in time Bob uploads his policies to the SIP proxy at 589 his VoIP providers SIP proxy. 591 PUT 592 /spit-policy/users/sip:bob@company-example.com/index/~~/ruleset 594 HTTP/1.1 595 Content-Type:application/spit+xml 596 Host: proxy.home-example.com 598 <<<< Added policies go in here. >>>> 599 [Editor's Note: In a future version an XML example 600 policy document will be listed here.] 602 Uploading Policies using XCAP 604 When BoB receives a call from his friends, alice@foo.example and 605 tony@bar.example.com, then all the rules related to the spit policy 606 are checked. Only the first rule (rule 1) matches and is applied. 607 Thus, the call is forwarded without any further checks based on Rule 608 1. The rules assume that the authenticated identity of the caller 609 has been verified. 611 When Bob receives a call from a co-worker, 612 Charlie@company-example.com, Rule 2 is applied since the domain part 613 in the rule matches the domain part of Charlie's identity. 615 Now, when Bob receives a contact from an unknown user, called Mallice 616 in this example. Rule 3 indicates that an extended return- 617 routability test using hashcash [I-D.jennings-sip-hashcash] is used 618 with the call being redirected to Bob's voicebox afterwards. This 619 exchange is shown in Figure 9. 621 UA Proxy Bob's 622 Malice Voicebox 623 | INVITE | | 624 |------------------------->|Puzzle: work=15; | 625 | |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; | 626 | 419 with Puzzle |image="NhhMQ2l7SE0VBmZFKksUC19ia04="; | 627 | |value=160 | 628 |<-------------------------| | 629 | | | 630 | ACK | | 631 |------------------------->| | 632 | |Puzzle: work=0; | 633 | |pre="VgVGYixbRg0mdSwTY3YIfCBuYmg="; | 634 | |image="NhhMQ2l7SE0VBmZFKksUC19ia04=" | 635 | INVITE with Solution |value=160 | 636 |------------------------->| INVITE | 637 | |------------------------------------->| 638 | | | 639 | | 180 Ringing | 640 | 180 Ringing |<-------------------------------------| 641 |<-------------------------| | 642 | | 200 OK | 643 | 200 OK |<-------------------------------------| 644 |<-------------------------| | 645 | | ACK | 646 |---------------------------------------------------------------->| 647 | | | 649 Figure 9: Example Exchange: Malice contacts Bob 651 Depending on the outcome of the exchange the call is forwarded to a 652 mailbox sip:voicebox@company-example.com (in case Malory returned the 653 correct solution, see Rule 4) or blocked in case an incorrect 654 response was provided. It might be quite easy to see how this rule 655 set can be extended to support other SPIT handling mechanisms as well 656 (e.g., CAPTCHAs, SIP Pay, etc.). 658 8. Security Considerations 660 This document aims to describe a framework for addressing Spam for 661 Internet Telephony (SPIT) in order to make it simple for users to 662 influence the behavior of SIP message routing with an emphasis on 663 SPIT prevention. 665 The framework relies on three building blocks, namely SIP Identity, 666 authorization policies based on Common Policy and Presence 667 Authorization Policy, and XCAP. 669 As a high-level overview, the framework allows the user to control 670 end-to-end connectivity at the SIP message routing level whereby the 671 glue that lets all parts fit together is based on authorization 672 policies. Several other solution components can be developed 673 independently and can be plugged into the framework as soon as 674 available. 676 It must be avoided to introduce Denial of Service attacks against the 677 recipient by misguiding him or her to install authorization policies 678 that allow senders to bypass the policies although that was never 679 intended by the recipient. Additionally, it must not be possible by 680 extensions to the authorization policy framework to create policies 681 to block legitimate senders or to stall the processing of the 682 authorization policy engine. 684 9. Acknowledgments 686 We would like to thank 688 Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva 689 Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for 690 their review comments to a pre-00 version. 691 Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski, 692 Saverio Niccolini, Albert Caruana, and Juergen Quittek for their 693 comments to the 00 version. 695 10. References 697 10.1. Normative References 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", March 1997. 702 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 703 Authenticated Identity Management in the Session 704 Initiation Protocol (SIP)", RFC 4474, August 2006. 706 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 707 Polk, J., and J. Rosenberg, "Common Policy: A Document 708 Format for Expressing Privacy Preferences", RFC 4745, 709 February 2007. 711 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 712 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 714 10.2. Informative References 716 [I-D.ietf-sipping-spam] 717 Rosenberg, J. and C. Jennings, "The Session Initiation 718 Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work 719 in progress), July 2007. 721 [I-D.ietf-simple-presence-rules] 722 Rosenberg, J., "Presence Authorization Rules", 723 draft-ietf-simple-presence-rules-10 (work in progress), 724 July 2007. 726 [I-D.jennings-sip-hashcash] 727 Jennings, C., "Computational Puzzles for SPAM Reduction in 728 SIP", draft-jennings-sip-hashcash-06 (work in progress), 729 July 2007. 731 [I-D.wing-sipping-spam-score] 732 Wing, D., "Spam Score for SIP", 733 draft-wing-sipping-spam-score-00 (work in progress), 734 August 2007. 736 [I-D.ietf-sip-consent-framework] 737 Rosenberg, J., Camarillo, G., and D. Willis, "A Framework 738 for Consent-based Communications in the Session Initiation 739 Protocol (SIP)", draft-ietf-sip-consent-framework-03 (work 740 in progress), November 2007. 742 [I-D.ietf-dkim-overview] 743 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 744 Identified Mail (DKIM) Service Overview", 745 draft-ietf-dkim-overview-07 (work in progress), 746 November 2007. 748 [I-D.tschofenig-sipping-spit-policy] 749 Tschofenig, H., "A Document Format for Expressing 750 Authorization Policies to tackle Spam and Unwanted 751 Communication for Internet Telephony", 752 draft-tschofenig-sipping-spit-policy-01 (work in 753 progress), July 2007. 755 [I-D.schwartz-sipping-spit-saml] 756 Schwartz, D., "SPAM for Internet Telephony (SPIT) 757 Prevention using the Security Assertion Markup Language 758 (SAML)", draft-schwartz-sipping-spit-saml-01 (work in 759 progress), June 2006. 761 [I-D.shacham-http-corr-uris] 762 Shacham, R. and H. Schulzrinne, "HTTP Header for Future 763 Correspondence Addresses", draft-shacham-http-corr-uris-00 764 (work in progress), May 2007. 766 [I-D.jennings-sipping-pay] 767 Jennings, C., "Payment for Services in Session Initiation 768 Protocol (SIP)", draft-jennings-sipping-pay-06 (work in 769 progress), July 2007. 771 [I-D.froment-sipping-spit-requirements] 772 Froment, T., "Requirements for Authorization Policies to 773 tackle Spam and Unwanted Communication for Internet 774 Telephony", draft-froment-sipping-spit-requirements-01 775 (work in progress), July 2007. 777 [I-D.niccolini-sipping-feedback-spit] 778 Niccolini, S., "SIP Extensions for SPIT identification", 779 draft-niccolini-sipping-feedback-spit-03 (work in 780 progress), February 2007. 782 [I-D.tschofenig-sipping-captcha] 783 Tschofenig, H. and E. Leppanen, "Completely Automated 784 Public Turing Test to Tell Computers and Humans Apart 785 (CAPTCHA) based Robot Challenges for the Session 786 Initiation Protocol (SIP)", 787 draft-tschofenig-sipping-captcha-00 (work in progress), 788 July 2007. 790 [Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt, 791 C., and H. Waack, "Developing a Legally Compliant 792 Reachability Management System as a Countermeasure against 793 SPIT, Third Annual VoIP Security Workshop, Berlin, 794 available at 795 https://tepin.aiki.de/blog/uploads/spit-al.pdf", 796 June 2006. 798 [Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen 799 Behandlung von Voice over IP (VoIP), available at 800 http://www.bundesnetzagentur.de/media/archive/3186.pdf", 801 September 2005. 803 [Law2] "70. Konferenz der Datenschutzbeauftragten des Bundes und 804 der Laender: Entschliessung Telefonieren mit 805 Internettechnologie (Voice over IP - VoIP), available at 806 http://www.datenschutzzentrum.de/material/themen/press 807 e/20051028-dsbk-voip.htm", Oktober 2005. 809 [Law3] "Working Party 29 Opinion 2/2006 on privacy issues related 810 to the provision of email screening services, WP 118, 811 available at http://ec.europa.eu/justice_home/fsj/privacy/ 812 docs/wpdocs/2006/wp118_en.pdf", February 2006. 814 Appendix A. Outside the Scope 816 We consider the following aspects outside the scope of this document: 818 o Mechanisms to publish SPIT causing parties on the Internet, i.e., 819 information about domains that create SPIT. 820 o Determining the source of unwanted traffic in real-time. 821 o Pushing packet filters and authorization policies towards the SPIT 822 sending domain. 824 Authors' Addresses 826 Hannes Tschofenig 827 Nokia Siemens Networks 828 Otto-Hahn-Ring 6 829 Munich, Bavaria 81739 830 Germany 832 Email: Hannes.Tschofenig@nsn.com 833 URI: http://www.tschofenig.com 835 Henning Schulzrinne 836 Columbia University 837 Department of Computer Science 838 450 Computer Science Building 839 New York, NY 10027 840 US 842 Phone: +1 212 939 7004 843 Email: hgs@cs.columbia.edu 844 URI: http://www.cs.columbia.edu 846 Dan Wing 847 Cisco Systems 849 Phone: 850 Email: dwing@cisco.com 851 Jonathan Rosenberg 852 Cisco Systems 853 600 Lanidex Plaza 854 Parsippany, New York 07054 855 USA 857 Email: jdrosen@cisco.com 858 URI: http://www.jdrosen.net 860 David Schwartz 861 Kayote Networks 862 Malcha Technology Park 863 Jerusalem 96951 864 Israel 866 Email: david.schwartz@kayote.com 868 Full Copyright Statement 870 Copyright (C) The IETF Trust (2007). 872 This document is subject to the rights, licenses and restrictions 873 contained in BCP 78, and except as set forth therein, the authors 874 retain all their rights. 876 This document and the information contained herein are provided on an 877 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 878 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 879 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 880 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 881 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 882 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 884 Intellectual Property 886 The IETF takes no position regarding the validity or scope of any 887 Intellectual Property Rights or other rights that might be claimed to 888 pertain to the implementation or use of the technology described in 889 this document or the extent to which any license under such rights 890 might or might not be available; nor does it represent that it has 891 made any independent effort to identify any such rights. Information 892 on the procedures with respect to rights in RFC documents can be 893 found in BCP 78 and BCP 79. 895 Copies of IPR disclosures made to the IETF Secretariat and any 896 assurances of licenses to be made available, or the result of an 897 attempt made to obtain a general license or permission for the use of 898 such proprietary rights by implementers or users of this 899 specification can be obtained from the IETF on-line IPR repository at 900 http://www.ietf.org/ipr. 902 The IETF invites any interested party to bring to its attention any 903 copyrights, patents or patent applications, or other proprietary 904 rights that may cover technology that may be required to implement 905 this standard. Please address the information to the IETF at 906 ietf-ipr@ietf.org. 908 Acknowledgment 910 Funding for the RFC Editor function is provided by the IETF 911 Administrative Support Activity (IASA).