idnits 2.17.00 (12 Aug 2021) /tmp/idnits65352/draft-tschofenig-sipping-framework-spit-reduction-03.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 924. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 935. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 942. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 948. 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 (February 25, 2008) is 5199 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 760, but no explicit reference was found in the text == Unused Reference: 'I-D.schwartz-sipping-spit-saml' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'I-D.niccolini-sipping-feedback-spit' is defined on line 803, 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: 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-02 == Outdated reference: A later version (-03) exists of draft-froment-sipping-spit-requirements-02 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: August 28, 2008 Columbia University 6 D. Wing 7 Cisco 8 J. Rosenberg 9 Cisco Systems 10 D. Schwartz 11 XConnect 12 February 25, 2008 14 A Framework to tackle Spam and Unwanted Communication for Internet 15 Telephony 16 draft-tschofenig-sipping-framework-spit-reduction-03.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 28, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 Spam, defined as sending unsolicited messages to someone in bulk, is 50 likely to become a problem on SIP open-wide deployed networks. A 51 number of solutions have been proposed for dealing with Spam for 52 Internet Telephony (SPIT) and unwanted communication, for example, 53 content filtering, black lists, white lists, consent-based 54 communication, reputation systems, address obfuscation, limited use 55 addresses, turing tests, computational puzzles, payments at risk, 56 circles of trust, and many others. 58 This document describes the big picture that illustrates how the 59 different building blocks fit together and can be deployed 60 incrementally. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 4. Communication Patterns and User Groups . . . . . . . . . . . . 7 68 4.1. Closed Groups . . . . . . . . . . . . . . . . . . . . . . 7 69 4.2. Semi-Open Groups . . . . . . . . . . . . . . . . . . . . . 7 70 4.3. Open Groups . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9 73 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9 74 5.1. Rule Enforcement via a Trusted Intermediary . . . . . . . 10 75 5.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 76 5.3. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 13 78 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17 83 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 84 Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 19 85 Appendix B. Authorization Engine in SIP UA . . . . . . . . . . . 19 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 87 Intellectual Property and Copyright Statements . . . . . . . . . . 22 89 1. Introduction 91 The problem of Spam for Internet Telephony (SPIT) is an imminent 92 challenge and only the combination of several techniques can provide 93 a framework for dealing with unwanted communication attempts. 95 [I-D.ietf-sipping-spam] provides four core recommendations that need 96 to be considered for a SPIT solution, namely 98 o Strong Identity 99 o White Lists 100 o Solve the Introduction Problem 101 o Don't Wait Until its Too Late 103 This document illustrates how existing building blocks can be put 104 together to form a solution to deal with SPIT. New building blocks 105 can be added to provide more efficient SPIT handling, since there is 106 no single solution that provides 100 % protection. 108 The purpose of this document defines a model of internal device 109 processing, protocol interfaces, and terminology to illustrate a way 110 in which SPIT prevention techniques can be added in a seamless 111 fashion. We focus only on the most important solution components and 112 consider many other aspects either outside the scope of this work 113 (see Appendix A) and postpone them for future work. 115 2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 119 document are to be interpreted as described in RFC 2119 [RFC2119]. 121 3. Framework 123 Figure 1 shows the interaction between the end host and a SIP proxy 124 belonging to its VoIP provider. One important part of the overall 125 solution is the ability to make authorization decisions based on 126 incoming communication attempts. The entity that writes these 127 authorization rules is referred as Rule Maker. The Rule Maker might 128 be a user via some form of user interface. Some rules may be 129 generated automatically by a piece of software by observing the users 130 behavior. Furthermore, in certain deployment environments an initial 131 rule set will be provided by some third party entity, such as the 132 enterprise system administrator or the VoIP provider. 134 Policies are processed by corresponding module within the SIP proxy, 135 called Authorization Engine, that interacts with the message routing 136 component. By following this architectural approach the Policy 137 Decision Point (PDP) and the Policy Enforcement Point (PEP) are 138 closely combined. As such, authorization policies are stored at at a 139 SIP proxy rather than the SIP UA client itself. The implications of 140 relocating these two functions, PDP and PEP, to the SIP UA client are 141 described in Appendix B. 143 +---------------------------------------------------------+ 144 | Authorization | 145 | re-route Policy +------------+ | 146 | ^ (implicit) ######| Rule Maker | | 147 | o +#######+ # +------------+ | 148 | o # # # | 149 | +---o----------#-------#--+ # Authorization | 150 | | o # # |<####### Policy | 151 +--------+ | | o Proxy # # | | 152 | | | | o # # |<*******************+ | 153 | Sender |<***>|+-------+ v # | * | 154 | | | ||Msg. | +-----------+| Authorization * | 155 +--------+ | ||Routing| | Authz. || Policy (explicit) * | 156 ^ o | ||Engine |<->| Engine |<#################+ * | 157 * o | |+-------+ +-----------+| # * | 158 * o | +-^--*--^-----------------+ # v | 159 * o | o * o +-------------+ | 160 * o | o * o | | | 161 * +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient/ | | 162 +**************************************************>| Rule Maker | | 163 | +-------------+ | 164 | | 165 | | 166 +-------------------Domain Boundary-----------------------+ 168 Legend: 170 oooo: SIP message interaction 171 ****: Protocol Interaction for authorizing the message sender 172 ####: Management of authorization policies 174 Figure 1: Overview 176 Assume that an arbitrary entity transmits a message to a specific URI 177 that finally hits the SIP proxy on the recipients side. Information 178 provided within that message are used as input to the rule 179 evaluation. Any part of the message may serve as input to the 180 evaluation process but for practical reasons only a few selected 181 fields do most of the work. The authenticated identity of the sender 182 is probably the most valuable information item. One could, however, 183 imagine that other information, such as reputation information 184 obtained from social networks, could offer additional input to the 185 authorization engine. 187 The protocol interaction for authorizing the message sender refers to 188 the ability of the recipient or the proxy to interact with the sender 189 to request authorization. The request for authorization might 190 require the message sender to be challenged (e.g., via hash cash 191 [I-D.jennings-sip-hashcash], via SIP payment 192 [I-D.jennings-sipping-pay], or via CAPTCHAs 193 [I-D.tschofenig-sipping-captcha]). Some other mechanisms, such as 194 SIP Identity do not require the verifying entity to challenge the 195 authentication service since the identity assertion is pushed towards 196 the recipient. 198 Figure 2 shows this integration step. The conditions part of the 199 rule offer a mechanisms to incrementally extend the overall framework 200 with new components. Depending on the outcome of the rule 201 evaluation, the message may be re-routed to another entity, such as 202 an answering machine, to the recipient, rejected or other actions are 203 triggered. The latter aspect is particularly interesting since it 204 allows further solution components to be executed. 206 SIP msg with 207 authenticated 208 identity +---------------+ 209 -------------->| |----------------> 210 Additional | | Spam marked msg 211 Msg fields | Authorization | 212 -------------->| Engine |----------------> 213 Other SPIT | | Re-routed msg 214 Prevention | | 215 Components | |----------------> 216 -------------->+---------------+ Forwarded to 217 | | original recipient 218 | | 219 <-----------+ +----------->|| 220 Politely blocked Blocked 222 Figure 2: Message Filtering and Routing 224 Note that some traffic analysis and consequently some form of content 225 filtering (e.g., of MESSAGEs) message be applied locally within the 226 VoIP provider's domain also under the control of the end user. 227 However, this is largely an implementation-specific technique without 228 protocol impact. For example, consider a VoIP provider that wants to 229 utilize a statistical analysis tool for Spam prevention. It is not 230 necessary to standardized the algorithms nor protocols; the impact 231 for the authorization policies is mainly the ability to allow the 232 Rule Maker to enable or to disable the usage of these statistical 233 techniques and potentially to map the output of the analysis process 234 to value range from 0 (i.e., the message is not classified as Spam) 235 and 100 (i.e., the message was classified as Spam). A Rule Maker may 236 decide to act with an appropriate action on a certain level of Spam 237 marking. 239 Authenticated Identities: 241 Initial VoIP provider are likely to secure their SIP signaling 242 using Transport Layer Security (TLS) or IP security (IPsec) 243 between neighboring providers and use P-Asserted-ID [RFC3325]. 245 Note: SIP Identity is comparable to DomainKeys Identified Mail 246 (DKIM) [I-D.ietf-dkim-overview] used for associating a 247 "responsible" identity with an email message and provides a 248 means of verifying that the association is legitimate. 250 SIP Identity [RFC4474] is a proposal for stronger security 251 mechanisms used to provide the verification service with the 252 authenticated identity. SIP Identity is a reasonably simple 253 specification and does not rely on a huge amount of infrastructure 254 support. 256 This framework does not assume a specific mechanism for asserting 257 identities to be used but a strong identity mechanism is a pre- 258 requisity for authorization policy handling to be successful. 260 Authorization Policies: 262 Even if policy decision making and policy enforcement is done 263 outside the SIP UA client then still there might not be a need to 264 standardize an authorization policy language if the policies can 265 be modified via a webpage. This approach of policy handling is 266 done in many cases today already for various applications. 268 Unfortunately, this approach tends to become cumbersome for end 269 users and therefore it is better to hide a lot of policy details 270 from the end user itself and to make use of context information, 271 for example, address books and authorization policies available 272 already created for presence based systems. 274 Additionally, a user may have multiple devices and a consistent 275 view of the policies should be provided. 277 An example solution for authorization policies for dealing with 278 reducing unwanted communication is described in 279 [I-D.tschofenig-sipping-spit-policy] with the requirements 280 detailed in [I-D.froment-sipping-spit-requirements]. 282 There is still one significant problem unsolved: since white lists 283 need to be created somehow and hence there is an introduction 284 problem. Section 4 discusses this aspect in more 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. 318 o strangers, divided into 'interesting' and 'uninteresting'. The 319 latter are messages from people that someone does not care to have 320 a conversation with or respond to, at least at that particular 321 moment. 323 Strangers can be defined by individual names or whole domains. A 324 special class of 'stranger' messages are transaction-related 325 communications, such as Instant Messaging or automated calls from an 326 airline or shipping company. 328 One way to deal with the introduction problem is to make use of 329 techniques like hash cash [I-D.jennings-sip-hashcash] or Completely 330 Automated Public Turing Test to Tell Computers and Humans Apart 331 (CAPTCHA) based robot challenges [I-D.tschofenig-sipping-captcha]. 332 Alternatively, a communication attempt may also be forwarded to an 333 answering maschine or alternative ways of establishing the initial 334 interaction may be proposed. 336 The usage of authorization policies for usage with Semi-Open Groups 337 is challenging but is considered manageable. 339 4.3. Open Groups 341 People in this type of group are not allowed to limit communication 342 attempts. Help desks, certain people in governmental agencies, 343 banks, insurance companies, etc. 345 For open groups a solution for providing SPIT prevention is far more 346 complicated. Consider a person working on a customer support 347 helpdesk. Ideally, they would like to receive only calls from 348 friendly customers (although the motivation for calling is most 349 likely a problem) and the topic of the calls only relates to problems 350 they are able to solve. Without listening to the caller they will 351 have a hard time to know whether the call could be classified as 352 SPIT. Another extreme case is a Public Safety Answering Point where 353 emergency service personell is not allowed to reject calls either. 355 Many SPIT prevention techniques might not be applicable since 356 blocking callers is likely not possible and applying other 357 techniques, such as turing tests, might not be ideal in an case of 358 open groups. 360 Statistical analysis may be helpful in some cases to deliver 361 additional information about the calling party. Social networks 362 might provide similar techniques based on reputation based systems. 364 4.4. Summary 366 Based on the discussions regarding communication patters and groups 367 the following observations can be made: 369 o A single person very likely has many roles and they may have an 370 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. 416 5.1. Rule Enforcement via a Trusted Intermediary 418 o Some from of strong identity assurance is required to build the 419 basis for identity-based authorization. SIP Identity [RFC4474] or 420 P-Asserted-ID [RFC3325] are examples of available mechanisms. 421 These mechanisms allow the authenticated identity of the sending 422 party to be determined. 423 o Authorization Policies based on the Common Policy framework 424 [RFC4745], as extended in [I-D.tschofenig-sipping-spit-policy] for 425 the purpose of SPIT prevention, are mandatory to implement at the 426 end host side and at the trusted intermediary. The implementation 427 of the rule evaluation engine might only be necessary on the 428 trusted VoIP proxy. Harmonization with the work done for presence 429 authorization [I-D.ietf-simple-presence-rules], which is based on 430 Common Policy [RFC4745], can be accomplished and is highly 431 desirable. 432 o XML Configuration Access Protocol (XCAP) [RFC4825] is used to 433 create, modify and delete authorization policies and is mandatory 434 to implement at the end host side and at the trusted intermediary. 436 5.2. Incremental Deployment 438 An important property is incremental deployment of additional 439 solution components that can be added and used when they become 440 available. This section aims to illustrate how the extensibility is 441 accomplished, based on an example. 443 Consider a VoIP provider that provides authorization policies that 444 provide the following functionality equivalent to the Common Policy 445 framework, i.e., identity-based, sphere and validity based conditions 446 initially. For actions only 'redirection' and 'blocking' is 447 provided. In our example we give this basic functionality the AUID 448 'new-spit-policy-example' with the namespace 449 'urn:ietf:params:xml:ns:new-spit-policy-example'. 451 When a client queries the capabilities of a SIP proxy in the VoIP 452 providers network using XCAP the following exchange may take place. 454 GET /xcap-caps/global/index HTTP/1.1 455 Host: xcap.example.com 457 Initial XCAP Query for Capabilities 459 HTTP/1.1 200 OK 460 Etag: "wwhha" 461 Content-Type: application/xcap-caps+xml 463 464 465 466 new-spit-policy-example 467 xcap-caps 468 469 470 urn:ietf:params:xml:ns:xcap-caps 471 urn:ietf:params:xml:ns:spit-policy 472 urn:ietf:params:xml:ns:common-policy 473 474 476 Initial XCAP Response with the supported Capabilities 478 As shown in the example above, Common Policy and the example SPIT 479 extension is implemented and the client can upload rules according to 480 the definition of the rule set functionality. 482 Later, when the VoIP provider updates the functionality of 483 authorization policies as more sophisticated mechanisms become 484 available and get implemented the functionality of the authorization 485 policy engine is enhanced with, for example, hashcash and the ability 486 to perform statistical analysis of signaling message. The latter 487 functionality comes with the ability to mark messages are Spam and 488 the ability for end users to enable/disable this functionality. We 489 use the namespaces 'urn:ietf:params:xml:ns:hashcash' and 490 'urn:ietf:params:xml:ns:statistical-analysis' for those. 492 A end user could now make use of these new functions and a capability 493 query of the SIP proxy would provide the following response. 495 GET /xcap-caps/global/index HTTP/1.1 496 Host: xcap.example.com 498 Second XCAP Query for Capabilities 500 HTTP/1.1 200 OK 501 Etag: "wwhha" 502 Content-Type: application/xcap-caps+xml 504 505 506 507 spit-policy 508 xcap-caps 509 hashcash 510 statistical-analysis 511 512 513 urn:ietf:params:xml:ns:spit-policy 514 urn:ietf:params:xml:ns:common-policy 515 urn:ietf:params:xml:ns:hashcash 516 urn:ietf:params:xml:ns:statistical-analysis 517 518 520 Second XCAP Response with the supported Capabilities 522 New SPIT handling functionality may extend condition, actions and/or 523 transformation elements of a rule. 525 5.3. Botnets 527 A botnet is a large number of compromised maschines that are used to 528 create and send spam or viruses or flood a network with messages as a 529 denial of service attack. 531 Such a botnet represents a significant challenge for a VoIP 532 infrastructure and also for the mechanisms proposed in this document. 533 Recently observed attacks indicated that some botnets tried to steal 534 credentials to distribute messages with "real" identities. To deal 535 with the threat it is useful to classify the behavior of these bots 536 into three categories, namely 538 o The botnet does not have access to the user's credentials. In 539 this case identity-based white lists provides adequate protection. 540 o The botnets does have access to user's credentials of compromised 541 maschines but distributes messages in a random fashion. In this 542 case identity-based white lists provides adequate protection since 543 it is unlikely that the recipient will have that person in their 544 whitelist. 545 o In this category the botnet has access to the user's credentials 546 and utilizes addresses from the user's addressbook. In this case 547 whitelists do not provide a proper protection. Since the 548 recipient knows the sender of the message it would, in many cases, 549 be able to get in contact with him or her and report the observed 550 problem. This approach does not work with a pure maschine-to- 551 maschine communication environment without user involvement. 553 6. Privacy Considerations 555 This document does not propose to distribute the user's authorization 556 policies to other VoIP providers nor is the configuration of policies 557 at SIP proxies other than the trusted user's VoIP provider necessary. 558 Furthemore, if blocking or influencing of the message processing is 559 executed by the VoIP provider then they have to be explicitly enabled 560 by the end user. Blocking of messages, even if it is based on 561 "super-clever" machine learning techniques often introduces 562 unpredictability. 564 Legal norms from fields of law can take regulative effects in the 565 context of SPIT processing, such as constitutional law, data 566 protection law, telecommunication law, teleservices law, criminal 567 law, and possibly administrative law. See, for example, [Law1], 568 [Law2] and [Law3]. For example, it is mandatory to pass full control 569 of SPIT filtering to the end user, as this minimises legal problems. 571 An overview about regulatory aspects can be found in [Spit-AL]. 573 7. Example 575 This section shows an example whereby we consider a user 576 Bob@company-example.com that writes (most likely via a nice user 577 interface) the following policies. We use a high-level language to 578 show the main idea of the policies. 580 RULE 1: 581 IF identity=alice@foo.example.com THEN ACCEPT 582 IF identity=tony@bar.example.com THEN ACCEPT 584 RULE 2: 585 IF domain=company-example.com THEN ACCEPT 587 RULE 3: 588 IF unauthenticated THEN 589 EXECUTE hashcash 591 RULE 4: 592 IF 593 THEN 594 REDIRECT sip:voicebox@company-example.com 596 RULE 5: 597 IF 598 THEN 599 block 601 Example of Bob's Rule Set 603 At some point in time Bob uploads his policies to the SIP proxy at 604 his VoIP providers SIP proxy. 606 PUT 607 /spit-policy/users/sip:bob@company-example.com/index/~~/ruleset 609 HTTP/1.1 610 Content-Type:application/spit+xml 611 Host: proxy.home-example.com 613 <<<< Added policies go in here. >>>> 614 [Editor's Note: In a future version an XML example 615 policy document will be listed here.] 617 Uploading Policies using XCAP 619 When BoB receives a call from his friends, alice@foo.example and 620 tony@bar.example.com, then all the rules related to the spit policy 621 are checked. Only the first rule (rule 1) matches and is applied. 622 Thus, the call is forwarded without any further checks based on Rule 623 1. The rules assume that the authenticated identity of the caller 624 has been verified. 626 When Bob receives a call from a co-worker, 627 Charlie@company-example.com, Rule 2 is applied since the domain part 628 in the rule matches the domain part of Charlie's identity. 630 Now, when Bob receives a contact from an unknown user, called Mallice 631 in this example. Rule 3 indicates that an extended return- 632 routability test using hashcash [I-D.jennings-sip-hashcash] is used 633 with the call being redirected to Bob's voicebox afterwards. This 634 exchange is shown in Figure 9. 636 UA Proxy Bob's 637 Malice Voicebox 638 | INVITE | | 639 |------------------------->|Puzzle: work=15; | 640 | |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; | 641 | 419 with Puzzle |image="NhhMQ2l7SE0VBmZFKksUC19ia04="; | 642 | |value=160 | 643 |<-------------------------| | 644 | | | 645 | ACK | | 646 |------------------------->| | 647 | |Puzzle: work=0; | 648 | |pre="VgVGYixbRg0mdSwTY3YIfCBuYmg="; | 649 | |image="NhhMQ2l7SE0VBmZFKksUC19ia04=" | 650 | INVITE with Solution |value=160 | 651 |------------------------->| INVITE | 652 | |------------------------------------->| 653 | | | 654 | | 180 Ringing | 655 | 180 Ringing |<-------------------------------------| 656 |<-------------------------| | 657 | | 200 OK | 658 | 200 OK |<-------------------------------------| 659 |<-------------------------| | 660 | | ACK | 661 |---------------------------------------------------------------->| 662 | | | 664 Figure 9: Example Exchange: Malice contacts Bob 666 Depending on the outcome of the exchange the call is forwarded to a 667 mailbox sip:voicebox@company-example.com (in case Malory returned the 668 correct solution, see Rule 4) or blocked in case an incorrect 669 response was provided. It might be quite easy to see how this rule 670 set can be extended to support other SPIT handling mechanisms as well 671 (e.g., CAPTCHAs, SIP Pay, etc.). 673 8. Security Considerations 675 This document aims to describe a framework for addressing Spam for 676 Internet Telephony (SPIT) in order to make it simple for users to 677 influence the behavior of SIP message routing with an emphasis on 678 SPIT prevention. 680 The framework relies on three building blocks, namely SIP Identity, 681 authorization policies based on Common Policy and Presence 682 Authorization Policy, and XCAP. 684 As a high-level overview, the framework allows the user to control 685 end-to-end connectivity at the SIP message routing level whereby the 686 glue that lets all parts fit together is based on authorization 687 policies. Several other solution components can be developed 688 independently and can be plugged into the framework as soon as 689 available. 691 It must be avoided to introduce Denial of Service attacks against the 692 recipient by misguiding him or her to install authorization policies 693 that allow senders to bypass the policies although that was never 694 intended by the recipient. Additionally, it must not be possible by 695 extensions to the authorization policy framework to create policies 696 to block legitimate senders or to stall the processing of the 697 authorization policy engine. 699 9. Acknowledgments 701 We would like to thank 703 Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva 704 Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for 705 their review comments to a pre-00 version. 706 Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski, 707 Saverio Niccolini, Albert Caruana, and Juergen Quittek for their 708 comments to the 00 version. 709 Otmar Lendl, Jan Seedorf, Saverio Niccolini, Kai Fischer, Joachim 710 Charzinski, Dan York, Peter Saint-Andre, Brian Azzopardi, Martin 711 Stiemerling, and Juergen Quittek for their comments to the -01/-02 712 version. 714 10. References 715 10.1. Normative References 717 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 718 Requirement Levels", March 1997. 720 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 721 Authenticated Identity Management in the Session 722 Initiation Protocol (SIP)", RFC 4474, August 2006. 724 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 725 Polk, J., and J. Rosenberg, "Common Policy: A Document 726 Format for Expressing Privacy Preferences", RFC 4745, 727 February 2007. 729 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 730 Extensions to the Session Initiation Protocol (SIP) for 731 Asserted Identity within Trusted Networks", RFC 3325, 732 November 2002. 734 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 735 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 737 10.2. Informative References 739 [I-D.ietf-sipping-spam] 740 Rosenberg, J. and C. Jennings, "The Session Initiation 741 Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work 742 in progress), July 2007. 744 [I-D.ietf-simple-presence-rules] 745 Rosenberg, J., "Presence Authorization Rules", 746 draft-ietf-simple-presence-rules-10 (work in progress), 747 July 2007. 749 [I-D.jennings-sip-hashcash] 750 Jennings, C., "Computational Puzzles for SPAM Reduction in 751 SIP", draft-jennings-sip-hashcash-06 (work in progress), 752 July 2007. 754 [I-D.wing-sipping-spam-score] 755 Wing, D., Niccolini, S., Stiemerling, M., and H. 756 Tschofenig, "Spam Score for SIP", 757 draft-wing-sipping-spam-score-02 (work in progress), 758 February 2008. 760 [I-D.ietf-sip-consent-framework] 761 Rosenberg, J., Camarillo, G., and D. Willis, "A Framework 762 for Consent-based Communications in the Session Initiation 763 Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work 764 in progress), January 2008. 766 [I-D.ietf-dkim-overview] 767 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 768 Identified Mail (DKIM) Service Overview", 769 draft-ietf-dkim-overview-09 (work in progress), 770 February 2008. 772 [I-D.tschofenig-sipping-spit-policy] 773 Tschofenig, H., Wing, D., Schulzrinne, H., Froment, T., 774 and G. Dawirs, "A Document Format for Expressing 775 Authorization Policies to tackle Spam and Unwanted 776 Communication for Internet Telephony", 777 draft-tschofenig-sipping-spit-policy-02 (work in 778 progress), November 2007. 780 [I-D.schwartz-sipping-spit-saml] 781 Schwartz, D., "SPAM for Internet Telephony (SPIT) 782 Prevention using the Security Assertion Markup Language 783 (SAML)", draft-schwartz-sipping-spit-saml-01 (work in 784 progress), June 2006. 786 [I-D.shacham-http-corr-uris] 787 Shacham, R. and H. Schulzrinne, "HTTP Header for Future 788 Correspondence Addresses", draft-shacham-http-corr-uris-00 789 (work in progress), May 2007. 791 [I-D.jennings-sipping-pay] 792 Jennings, C., "Payment for Services in Session Initiation 793 Protocol (SIP)", draft-jennings-sipping-pay-06 (work in 794 progress), July 2007. 796 [I-D.froment-sipping-spit-requirements] 797 Tschofenig, H., Dawirs, G., Froment, T., Wing, D., and H. 798 Schulzrinne, "Requirements for Authorization Policies to 799 tackle Spam and Unwanted Communication for Internet 800 Telephony", draft-froment-sipping-spit-requirements-02 801 (work in progress), February 2008. 803 [I-D.niccolini-sipping-feedback-spit] 804 Niccolini, S., "SIP Extensions for SPIT identification", 805 draft-niccolini-sipping-feedback-spit-03 (work in 806 progress), February 2007. 808 [I-D.tschofenig-sipping-captcha] 809 Tschofenig, H., Leppanen, E., Niccolini, S., and M. 810 Arumaithurai, "Completely Automated Public Turing Test to 811 Tell Computers and Humans Apart (CAPTCHA) based Robot 812 Challenges for SIP", draft-tschofenig-sipping-captcha-01 813 (work in progress), February 2008. 815 [Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt, 816 C., and H. Waack, "Developing a Legally Compliant 817 Reachability Management System as a Countermeasure against 818 SPIT, Third Annual VoIP Security Workshop, Berlin, 819 available at 820 https://tepin.aiki.de/blog/uploads/spit-al.pdf", 821 June 2006. 823 [Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen 824 Behandlung von Voice over IP (VoIP), available at 825 http://www.bundesnetzagentur.de/media/archive/3186.pdf", 826 September 2005. 828 [Law2] "70. Konferenz der Datenschutzbeauftragten des Bundes und 829 der Laender: Entschliessung Telefonieren mit 830 Internettechnologie (Voice over IP - VoIP), available at 831 http://www.datenschutzzentrum.de/material/themen/press 832 e/20051028-dsbk-voip.htm", Oktober 2005. 834 [Law3] "Working Party 29 Opinion 2/2006 on privacy issues related 835 to the provision of email screening services, WP 118, 836 available at http://ec.europa.eu/justice_home/fsj/privacy/ 837 docs/wpdocs/2006/wp118_en.pdf", February 2006. 839 Appendix A. Outside the Scope 841 We consider the following aspects outside the scope of this document: 843 o Mechanisms to publish SPIT causing parties on the Internet, i.e., 844 information about domains that create SPIT. 845 o Determining the source of unwanted traffic in real-time. 846 o Pushing packet filters and authorization policies towards the SPIT 847 sending domain. 849 Appendix B. Authorization Engine in SIP UA 851 When white lists are stored and managed only at the SIP UA client 852 then the authorization policies language and the protocol to modify 853 the policies do not need to be standardized; they are purely 854 implementation specific details. 856 While this appears to be an advantage there are various drawbacks 857 including the inability to synchronize policies among different 858 devices. Additionally, some information that is typically available 859 to the Policy Decision Point may not be available to the end host. 860 To avoid standardizing the exchange of such type of information an 861 abstract form of Spam marking is proposed in 862 [I-D.wing-sipping-spam-score]. 864 Authors' Addresses 866 Hannes Tschofenig 867 Nokia Siemens Networks 868 Otto-Hahn-Ring 6 869 Munich, Bavaria 81739 870 Germany 872 Email: Hannes.Tschofenig@nsn.com 873 URI: http://www.tschofenig.com 875 Henning Schulzrinne 876 Columbia University 877 Department of Computer Science 878 450 Computer Science Building 879 New York, NY 10027 880 US 882 Phone: +1 212 939 7004 883 Email: hgs@cs.columbia.edu 884 URI: http://www.cs.columbia.edu 886 Dan Wing 887 Cisco Systems, Inc. 888 170 West Tasman Drive 889 San Jose, CA 95134 890 USA 892 Email: dwing@cisco.com 893 Jonathan Rosenberg 894 Cisco Systems 895 600 Lanidex Plaza 896 Parsippany, New York 07054 897 USA 899 Email: jdrosen@cisco.com 900 URI: http://www.jdrosen.net 902 David Schwartz 903 XConnect 904 Malcha Technology Park 905 Jerusalem, 96951 906 Israel 908 Email: dschwartz@xconnect.net 910 Full Copyright Statement 912 Copyright (C) The IETF Trust (2008). 914 This document is subject to the rights, licenses and restrictions 915 contained in BCP 78, and except as set forth therein, the authors 916 retain all their rights. 918 This document and the information contained herein are provided on an 919 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 920 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 921 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 922 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 923 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 924 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 926 Intellectual Property 928 The IETF takes no position regarding the validity or scope of any 929 Intellectual Property Rights or other rights that might be claimed to 930 pertain to the implementation or use of the technology described in 931 this document or the extent to which any license under such rights 932 might or might not be available; nor does it represent that it has 933 made any independent effort to identify any such rights. Information 934 on the procedures with respect to rights in RFC documents can be 935 found in BCP 78 and BCP 79. 937 Copies of IPR disclosures made to the IETF Secretariat and any 938 assurances of licenses to be made available, or the result of an 939 attempt made to obtain a general license or permission for the use of 940 such proprietary rights by implementers or users of this 941 specification can be obtained from the IETF on-line IPR repository at 942 http://www.ietf.org/ipr. 944 The IETF invites any interested party to bring to its attention any 945 copyrights, patents or patent applications, or other proprietary 946 rights that may cover technology that may be required to implement 947 this standard. Please address the information to the IETF at 948 ietf-ipr@ietf.org. 950 Acknowledgment 952 Funding for the RFC Editor function is provided by the IETF 953 Administrative Support Activity (IASA).