idnits 2.17.00 (12 Aug 2021) /tmp/idnits64403/draft-tschofenig-sipping-framework-spit-reduction-01.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 855. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 873. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 879. 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 (July 8, 2007) is 5431 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 713, 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 (-06) exists of draft-jennings-sip-hashcash-05 == 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-00 == Outdated reference: A later version (-06) exists of draft-jennings-sipping-pay-05 == Outdated reference: A later version (-03) exists of draft-froment-sipping-spit-requirements-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 Network Working Group H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational H. Schulzrinne 5 Expires: January 9, 2008 Columbia University 6 D. Wing 7 J. Rosenberg 8 Cisco Systems 9 D. Schwartz 10 Kayote Networks 11 July 8, 2007 13 A Framework to tackle Spam and Unwanted Communication for Internet 14 Telephony 15 draft-tschofenig-sipping-framework-spit-reduction-01.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 January 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9 70 5.1. End Host based Rule Enforcement . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 15 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 16 80 Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 82 Intellectual Property and Copyright Statements . . . . . . . . . . 20 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, 105 which define a way in which we can plug-in future protocols. We 106 focus only on the most important solution components and consider 107 many other aspects either outside the scope of this work (see 108 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 offload some authorization 122 decisions to the VoIP provider which can save bandwidth and activity 123 on the SIP UA. 125 Figure 1 below shows the interaction between the end host and a SIP 126 proxy belonging to its VoIP provider. The end user, in the role of a 127 recipient for communication attempts, uploads authorization policies. 128 These policies are processed by corresponding module within the SIP 129 proxy, called Authorization Engine, that interacts with the message 130 routing functionality. A part of the rule set might, however, also 131 be created automatically as part of interactive interactions (e.g., 132 monitoring ongoing communication attempts). 134 +---------------------------------------------------------+ 135 | Authorization | 136 | re-route Policy | 137 | ^ (implicit) | 138 | o +#######+ | 139 | o # # | 140 | +---o----------#-------#--+ | 141 | | o # # | | 142 +--------+ | | o Proxy # # | | 143 | | | | o # # |<*******************+ | 144 | Sender |<***>|+-------+ v # | * | 145 | | | ||Msg. | +-----------+| Authorization * | 146 +--------+ | ||Routing| | Authz. || Policy (explicit) * | 147 ^ o | ||Engine |<->| Engine |<#################+ * | 148 * o | |+-------+ +-----------+| # * | 149 * o | +-^--*--^-----------------+ # v | 150 * o | o * o +-------------+ | 151 * o | o * o | | | 152 * +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient | | 153 +**************************************************>| | | 154 | +-------------+ | 155 | | 156 | | 157 +-------------------Domain Boundary-----------------------+ 159 Legend: 161 oooo: SIP message interaction 162 ****: Protocol Interaction for authorizing the message sender 163 ####: Management of authorization policies 165 Figure 1: Overview 167 Assume that an arbitrary sender transmits a message towards the 168 recipients URI that finally hits the SIP proxy on the recipients 169 side. Information provided within that message are used as input to 170 the rule evaluation. Any part of the message may serve as input to 171 the evaluation process but for practical reasons only a few selected 172 fields do most of the work. In this document, we argue that the 173 authenticated identity of the sender is the most valuable information 174 item. In the future, when standardization progresses then, for 175 example, reputation information obtained from social networks may 176 offer additional input to the authorization process. The protocol 177 interaction for authorizing the message sender refers to the ability 178 of the recipient or the proxy to interact with the sender to request 179 authorization. The request for authorization is a pull model whereby 180 the proxy or the recipient challenges the sender (e.g., via hash cash 181 [I-D.jennings-sip-hashcash], or SIP payment 182 [I-D.jennings-sipping-pay], or Completely Automated Public Turing 183 Test to Tell Computers and Humans Apart (CAPTCHA) based robot 184 challenges [I-D.tschofenig-sipping-captcha]) for authorization. SIP 185 Identity on the other hand realizes as push model whereby 186 authentication information is pushed towards the recipient. 188 Figure 2 shows this integration step. The conditions part of the 189 rule offer a mechanisms to incrementally extend the overall framework 190 with new SPIT prevention solution components. Depending on the rule 191 evaluation the message may be rerouted to another entity, such as an 192 answering machine, to the recipient, rejected or other actions are 193 triggered. The latter aspect is particularly interesting since it 194 allows further solution components to be executed. For example, a 195 permission request as part of the consent framework. 197 SIP msg with 198 authenticated 199 identity +---------------+ 200 -------------->| |----------------> 201 Additional | | Spam marked msg 202 Msg fields | Authorization | 203 -------------->| Engine |----------------> 204 Other SPIT | | Re-routed msg 205 Prevention | | 206 Components | |----------------> 207 -------------->+---------------+ Forwarded to 208 | | original recipient 209 | | 210 <-----------+ +----------->|| 211 Politely blocked Blocked 213 Figure 2: Message Filtering and Routing 215 Note that some traffic analysis and consequently some form of content 216 filtering (e.g., of MESSAGEs) can be applied locally within the VoIP 217 provider's domain also under the control of the end user. For 218 example, consider a Voice over IP provider that wants to utilize a 219 statistical analysis tool for Spam prevention. It is not necessary 220 to standardized the algorithms; the impact for the authorization 221 policies is mainly the ability to allow a Rule Maker to enable or to 222 disable the usage of these statistical techniques for SPIT filtering 223 and potentially to map the output of the analysis process to value 224 range from 0 (i.e., the message is not classified as Spam) and 100 225 (i.e., the message was classified as Spam). Conveying Spam marking 226 is proposed in [I-D.schwartz-sipping-spit-saml] and in 227 [I-D.niccolini-sipping-feedback-spit]. A Rule Maker may decide to 228 act with an appropriate action on such a Spam marking. 230 In a minimalistic SPIT framework only authenticated identities in 231 combination with authorization policies are used. This should serve 232 as a starting point for future work. 234 Authenticated Identities: 236 SIP Identity [RFC4474] is assumed to be used to provide the 237 receiver of a communication attempt with the authenticated 238 identity. SIP Identity is a reasonable simple specification and 239 does not rely on a huge amount of infrastructure support. 241 Note: SIP Identity is comparable to DomainKeys Identified Mail 242 (DKIM) [I-D.ietf-dkim-overview] used for associating a 243 "responsible" identity with an email message and provides a 244 means of verifying that the association is legitimate. 246 Authorization Policies: 248 When the white lists are stored and managed only at the end host 249 then the authorization policies and the protocol to modify the 250 policies do not need to be standardized since they are purely 251 implementation specific details. Even if the authorization 252 policies are managed centrally or some amount of policy 253 enforcement is done by trusted intermediaries then still there 254 might not be a need to standardize an authorization policy 255 language if the policies can be modified via a webpage. This type 256 of policy handling is done in many cases today already for various 257 applications. 259 Unfortunately, this approach tends to become cumbersome to manage 260 for end users and therefore it is useful to hide a lot of policy 261 details from the end user itself and to make use of context 262 information, for example, address books and authorization policies 263 available already created for presence based systems. 265 In some cases the above-described approach is not sufficient 266 whereby it is necessary to define a standardized protocol, for 267 example, if policies are used by different entities, created and 268 modified in an automatic way and when multiple entities manipulate 269 policies (potentially on behalf of the person affected by the 270 policies), e.g., the user may have multiple devices. 272 An example solution for authorization policies providing Spam 273 prevention capabilities are described in 274 [I-D.tschofenig-sipping-spit-policy] with the requirements 275 detailed in [I-D.froment-sipping-spit-requirements]. 277 The white list needs to be created somehow and hence there is an 278 introduction problem. Section 4 discusses this aspect in more 279 details. 281 4. Communication Patterns and User Groups 283 When communication takes place then at least three types of groups 284 can be identified. 286 4.1. Closed Groups 288 People in this group communicate only with the peers in their group. 289 They do not appreciate communication attempts from outside. 290 Communication is possible only for people within this list. Here is 291 an example of a closed group: Consider parents that do not want their 292 children from getting contaced by strangers. Hence, they may create 293 a white list containing the identifies of known friends, parents and 294 other relatives on behalf of their kids. 296 The usage of authorization policies for usage with Closed Groups is 297 straight forward. 299 4.2. Semi-Open Groups 301 In a semi-open environment all members of the same group are allowed 302 to get in contact with everyone else (e.g., for example in a company 303 environment). For members outside the company the communication 304 patters depend on the role of the person (e.g., standardization 305 people, sales people, etc.) and on the work style of the person. 307 For this category we distinguish a number of (non-spam) message 308 sources based on their characteristics: 310 o "friends" or "acquaintances", i.e., those we have communicated 311 with before. 312 o strangers, divided into 'interesting' and 'uninteresting'. The 313 latter are messages from people that someone does not care to have 314 a conversation with or respond to, at least at that particular 315 moment. 317 Strangers can be defined by individual names or whole domains. A 318 special class of 'stranger' messages are transaction-related 319 communications, such as Instant Messaging or automated calls from an 320 airline or shipping company. 322 The usage of authorization policies for usage with Semi-Open Groups 323 can be considered manageable. 325 In the PSTN a certain amount of protection against unwanted calls is 326 provided due to costs for phone calls. With almost free calls (or 327 instant messages) it might be necessary to abandon the idea of 328 allowing end-to-end real-time message delivery in all cases in order 329 to avoid the alerting the user. 331 4.3. Open Groups 333 People in this type of group are not allowed to limit communication 334 attempts. Help desks, certain people in governmental agencies, 335 banks, insurance companies, etc. 337 For Open Groups the situation is more complicated. Consider a person 338 working on a customer support helpdesk. Ideally, they would like to 339 receive only calls from friendly customers (although the motivation 340 for calling is most likely a problem) and the topic of the calls only 341 relates to problems they are able to solve. Without listening to the 342 caller they will have a hard time to know whether the call could be 343 classified as SPIT. Many SPIT prevention techniques might not be 344 applicable since blocking callers is likely not possible and applying 345 other techniques, such as turing tests, might not be ideal in an case 346 of Open Groups. 348 4.4. Summary 350 Based on the discussions regarding communication patters and groups 351 the following observations can be made: 353 o A single person very likely has many roles and they may have an 354 impact on the communication patterns. 355 For example, consider a person who is working in a company but 356 also want to be available for family members. 357 o The context in which a person is may change at any time. For 358 example, a person might be available for family members while at 359 work except during an important meeting where communication 360 attempts may be rejected. Switching a context has an impact for 361 reachability and the means for communicating with a specific 362 recipient, based on enabled rule sets. 364 From an authorization policy point of view it is important to be able 365 to express a sphere, i.e., the state a user is in and to switch 366 between different spheres easily by thereby switching to a different 367 rule set. 369 4.5. Usability 371 An important aspect in the usage of authorization policies is to 372 assist the user when creating policies. Ideally, the policies should 373 be established automatically. Below, there are a couple of examples 374 to illustrate the idea given that these aspects are largely 375 implementation issues: 377 o It must be possible for the proxy to automatically add addresses 378 on outbound messages and calls to the rule set. This approach is 379 similar to stateful packet filtering firewalls where outbound 380 packets establish state at the firewall to allow inbound packets 381 to traverse it again. 382 o Already available information in the address book can be used for 383 building the policy rules there is quite likely already a 384 relationship available with these persons existent. 385 o A large amount of email is non-personal, automated communication, 386 such as newsletters, confirmations and legitimate advertisements. 387 These are often tagged as spam by content filters. This type of 388 correspondence is usually initiated by a transaction over the web, 389 such as a purchase or signing up for a service. 390 [I-D.shacham-http-corr-uris], for example, defines an HTTP header 391 for conveying future correspondence addresses that can be 392 integrated in the rule set. 394 5. Protocol Interactions 396 This section describes the necessary building blocks that are 397 necessary to tie the framework together. We will describe two 398 different environments, namely one where rule enforcement happens at 399 the end host and another one where a trusted network intermediary 400 performs the actions. 402 5.1. End Host based Rule Enforcement 404 o SIP Identity [RFC4474] is mandatory to implement at the end host 405 and used to determine the authenticated identity of the sending 406 side. 407 o Authorization policies are purely implementation specific matter. 409 Since a purely end host based rule enforcement suffers from a number 410 of drawbacks, rule enforcement by a trusted intermediary is also 411 offered. 413 5.2. Rule Enforcement via a Trusted Intermediary 415 o SIP Identity [RFC4474] or a corresponding mechanism is mandatory 416 to implement at the trusted intermediary (e.g., the immediate VoIP 417 provider) and it determines the authenticated identity of the 418 sending side. 419 o Authorization Policies based on the Common Policy framework 420 [RFC4745], as extended in [I-D.tschofenig-sipping-spit-policy] for 421 the purpose of SPIT prevention, are mandatory to implement at the 422 end host side and at the trusted intermediary. The implementation 423 of the rule evaluation engine might only be necessary on the 424 trusted VoIP proxy. Harmonization with the work done for presence 425 authorization [I-D.ietf-simple-presence-rules], which is based on 426 Common Policy [RFC4745], can be accomplished and is highly 427 desirable. 428 o XML Configuration Access Protocol (XCAP) [RFC4825] is used to 429 create, modify and delete authorization policies and is mandatory 430 to implement at the end host side and at the trusted intermediary. 432 5.3. Incremental Deployment 434 An important property is incremental deployment of additional 435 solution components that can be added and used when they become 436 available. This section aims to illustrate how the extensibility is 437 accomplished, based on an example. 439 Consider a VoIP provider that provides authorization policies that 440 provide the following functionality equivalent to the Common Policy 441 framework, i.e., identity-based, sphere and validity based conditions 442 initially. For actions only 'redirection' and 'blocking' is 443 provided. In our example we give this basic functionality the AUID 444 'new-spit-policy-example' with the namespace 445 'urn:ietf:params:xml:ns:new-spit-policy-example'. 447 When a client queries the capabilities of a SIP proxy in the VoIP 448 providers network using XCAP the following exchange may take place. 450 GET /xcap-caps/global/index HTTP/1.1 451 Host: xcap.example.com 453 Initial XCAP Query for Capabilities 455 HTTP/1.1 200 OK 456 Etag: "wwhha" 457 Content-Type: application/xcap-caps+xml 459 460 461 462 new-spit-policy-example 463 xcap-caps 464 465 466 urn:ietf:params:xml:ns:xcap-caps 467 urn:ietf:params:xml:ns:spit-policy 468 urn:ietf:params:xml:ns:common-policy 469 470 472 Initial XCAP Response with the supported Capabilities 474 As shown in the example above, Common Policy and the example SPIT 475 extension is implemented and the client can upload rules according to 476 the definition of the rule set functionality. 478 Later, when the VoIP provider updates the functionality of 479 authorization policies as more sophisticated mechanisms become 480 available and get implemented the functionality of the authorization 481 policy engine is enhanced with, for example, hashcash and the ability 482 to perform statistical analysis of signaling message. The latter 483 functionality comes with the ability to mark messages are Spam and 484 the ability for end users to enable/disable this functionality. We 485 use the namespaces 'urn:ietf:params:xml:ns:hashcash' and 486 'urn:ietf:params:xml:ns:statistical-analysis' for those. 488 A end user could now make use of these new functions and a capability 489 query of the SIP proxy would provide the following response. 491 GET /xcap-caps/global/index HTTP/1.1 492 Host: xcap.example.com 494 Second XCAP Query for Capabilities 496 HTTP/1.1 200 OK 497 Etag: "wwhha" 498 Content-Type: application/xcap-caps+xml 500 501 502 503 spit-policy 504 xcap-caps 505 hashcash 506 statistical-analysis 507 508 509 urn:ietf:params:xml:ns:spit-policy 510 urn:ietf:params:xml:ns:common-policy 511 urn:ietf:params:xml:ns:hashcash 512 urn:ietf:params:xml:ns:statistical-analysis 513 514 516 Second XCAP Response with the supported Capabilities 518 New SPIT handling functionality may extend condition, actions and/or 519 transformation elements of a rule. 521 6. Privacy Considerations 523 This document does not propose to distribute the user's authorization 524 policies to other VoIP providers nor is the configuration of policies 525 at SIP proxies other than the trusted user's VoIP provider necessary. 526 Furthemore, if blocking or influencing of the message processing is 527 executed by the VoIP provider then they have to be explicitly enabled 528 by the end user. Blocking of messages, even if it is based on 529 "super-clever" machine learning techniques often introduces 530 unpredictability. 532 Legal norms from fields of law can take regulative effects in the 533 context of SPIT processing, such as constitutional law, data 534 protection law, telecommunication law, teleservices law, criminal 535 law, and possibly administrative law. See, for example, [Law1], 536 [Law2] and [Law3]. For example, it is mandatory to pass full control 537 of SPIT filtering to the end user, as this minimises legal problems. 539 An overview about regulatory aspects can be found in [Spit-AL]. 541 7. Example 543 This section shows an example whereby we consider a user 544 Bob@company-example.com that writes (most likely via a nice user 545 interface) the following policies. We use a high-level language to 546 show the main idea of the policies. 548 RULE 1: 549 IF identity=alice@foo.example.com THEN ACCEPT 550 IF identity=tony@bar.example.com THEN ACCEPT 552 RULE 2: 553 IF domain=company-example.com THEN ACCEPT 555 RULE 3: 556 IF unauthenticated THEN 557 EXECUTE hashcash 559 RULE 4: 560 IF 561 THEN 562 REDIRECT sip:voicebox@company-example.com 564 RULE 5: 565 IF 566 THEN 567 block 569 Example of Bob's Rule Set 571 At some point in time Bob uploads his policies to the SIP proxy at 572 his VoIP providers SIP proxy. 574 PUT 575 /spit-policy/users/sip:bob@company-example.com/index/~~/ruleset 577 HTTP/1.1 578 Content-Type:application/spit+xml 579 Host: proxy.home-example.com 581 <<<< Added policies go in here. >>>> 582 [Editor's Note: In a future version an XML example 583 policy document will be listed here.] 585 Uploading Policies using XCAP 587 When BoB receives a call from his friends, alice@foo.example and 588 tony@bar.example.com, then all the rules related to the spit policy 589 are checked. Only the first rule (rule 1) matches and is applied. 590 Thus, the call is forwarded without any further checks based on Rule 591 1. The rules assume that the authenticated identity of the caller 592 has been verified. 594 When Bob receives a call from a co-worker, 595 Charlie@company-example.com, Rule 2 is applied since the domain part 596 in the rule matches the domain part of Charlie's identity. 598 Now, when Bob receives a contact from an unknown user, called Mallice 599 in this example. Rule 3 indicates that an extended return- 600 routability test using hashcash [I-D.jennings-sip-hashcash] is used 601 with the call being redirected to Bob's voicebox afterwards. This 602 exchange is shown in Figure 9. 604 UA Proxy Bob's 605 Malice Voicebox 606 | INVITE | | 607 |------------------------->|Puzzle: work=15; | 608 | |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; | 609 | 419 with Puzzle |image="NhhMQ2l7SE0VBmZFKksUC19ia04="; | 610 | |value=160 | 611 |<-------------------------| | 612 | | | 613 | ACK | | 614 |------------------------->| | 615 | |Puzzle: work=0; | 616 | |pre="VgVGYixbRg0mdSwTY3YIfCBuYmg="; | 617 | |image="NhhMQ2l7SE0VBmZFKksUC19ia04=" | 618 | INVITE with Solution |value=160 | 619 |------------------------->| INVITE | 620 | |------------------------------------->| 621 | | | 622 | | 180 Ringing | 623 | 180 Ringing |<-------------------------------------| 624 |<-------------------------| | 625 | | 200 OK | 626 | 200 OK |<-------------------------------------| 627 |<-------------------------| | 628 | | ACK | 629 |---------------------------------------------------------------->| 630 | | | 632 Figure 9: Example Exchange: Malice contacts Bob 634 Depending on the outcome of the exchange the call is forwarded to a 635 mailbox sip:voicebox@company-example.com (in case Malory returned the 636 correct solution, see Rule 4) or blocked in case an incorrect 637 response was provided. It might be quite easy to see how this rule 638 set can be extended to support other SPIT handling mechanisms as well 639 (e.g., CAPTCHAs, SIP Pay, etc.). 641 8. Security Considerations 643 This document aims to describe a framework for addressing Spam for 644 Internet Telephony (SPIT) in order to make it simple for users to 645 influence the behavior of SIP message routing with an emphasis on 646 SPIT prevention. 648 The framework relies on three building blocks, namely SIP Identity, 649 authorization policies based on Common Policy and Presence 650 Authorization Policy, and XCAP. 652 As a high-level overview, the framework allows the user to control 653 end-to-end connectivity at the SIP message routing level whereby the 654 glue that lets all parts fit together is based on authorization 655 policies. Several other solution components can be developed 656 independently and can be plugged into the framework as soon as 657 available. 659 It must be avoided to introduce Denial of Service attacks against the 660 recipient by misguiding him or her to install authorization policies 661 that allow senders to bypass the policies although that was never 662 intended by the recipient. Additionally, it must not be possible by 663 extensions to the authorization policy framework to create policies 664 to block legitimate senders or to stall the processing of the 665 authorization policy engine. 667 9. Acknowledgments 669 We would like to thank 671 Jeremy Barkan, Dan York, Alexey Melnikov, Thomas Schreck, Eva 672 Leppanen, Cullen Jennings, Marit Hansen and Markus Hansen for 673 their review comments to a pre-00 version. 674 Jeremy Barkan, Eva Leppanen, Michaela Greiler, Joachim Charzinski, 675 Saverio Niccolini, Albert Caruana, and Juergen Quittek for their 676 comments to the 00 version. 678 10. References 679 10.1. Normative References 681 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 682 Requirement Levels", March 1997. 684 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 685 Authenticated Identity Management in the Session 686 Initiation Protocol (SIP)", RFC 4474, August 2006. 688 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 689 Polk, J., and J. Rosenberg, "Common Policy: A Document 690 Format for Expressing Privacy Preferences", RFC 4745, 691 February 2007. 693 [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) 694 Configuration Access Protocol (XCAP)", RFC 4825, May 2007. 696 10.2. Informative References 698 [I-D.ietf-sipping-spam] 699 Jennings, C. and J. Rosenberg, "The Session Initiation 700 Protocol (SIP) and Spam", draft-ietf-sipping-spam-04 (work 701 in progress), February 2007. 703 [I-D.ietf-simple-presence-rules] 704 Rosenberg, J., "Presence Authorization Rules", 705 draft-ietf-simple-presence-rules-09 (work in progress), 706 March 2007. 708 [I-D.jennings-sip-hashcash] 709 Jennings, C., "Computational Puzzles for SPAM Reduction in 710 SIP", draft-jennings-sip-hashcash-05 (work in progress), 711 June 2007. 713 [I-D.ietf-sip-consent-framework] 714 Rosenberg, J., "A Framework for Consent-Based 715 Communications in the Session Initiation Protocol (SIP)", 716 draft-ietf-sip-consent-framework-02 (work in progress), 717 July 2007. 719 [I-D.ietf-dkim-overview] 720 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 721 Identified Mail (DKIM) Message Signing Service Overview", 722 draft-ietf-dkim-overview-05 (work in progress), June 2007. 724 [I-D.tschofenig-sipping-spit-policy] 725 Tschofenig, H., "Anti-SPIT : A Document Format for 726 Expressing Anti-SPIT Authorization Policies", 727 draft-tschofenig-sipping-spit-policy-00 (work in 728 progress), February 2007. 730 [I-D.schwartz-sipping-spit-saml] 731 Schwartz, D., "SPAM for Internet Telephony (SPIT) 732 Prevention using the Security Assertion Markup Language 733 (SAML)", draft-schwartz-sipping-spit-saml-01 (work in 734 progress), June 2006. 736 [I-D.shacham-http-corr-uris] 737 Shacham, R. and H. Schulzrinne, "HTTP Header for Future 738 Correspondence Addresses", draft-shacham-http-corr-uris-00 739 (work in progress), May 2007. 741 [I-D.jennings-sipping-pay] 742 Jennings, C., "Payment for Services in Session Initiation 743 Protocol (SIP)", draft-jennings-sipping-pay-05 (work in 744 progress), October 2006. 746 [I-D.froment-sipping-spit-requirements] 747 Froment, T., "Requirements for Authorization Policies to 748 tackle Spam for Internet Telephony and Unwanted Traffic", 749 draft-froment-sipping-spit-requirements-00 (work in 750 progress), June 2007. 752 [I-D.niccolini-sipping-feedback-spit] 753 Niccolini, S., "SIP Extensions for SPIT identification", 754 draft-niccolini-sipping-feedback-spit-03 (work in 755 progress), February 2007. 757 [I-D.tschofenig-sipping-captcha] 758 Tschofenig, H. and E. Leppanen, "Completely Automated 759 Public Turing Test to Tell Computers and Humans Apart 760 (CAPTCHA) based Robot Challenges for the Session 761 Initiation Protocol (SIP)", July 2007. 763 [Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt, 764 C., and H. Waack, "Developing a Legally Compliant 765 Reachability Management System as a Countermeasure against 766 SPIT, Third Annual VoIP Security Workshop, Berlin, 767 available at 768 https://tepin.aiki.de/blog/uploads/spit-al.pdf", 769 June 2006. 771 [Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen 772 Behandlung von Voice over IP (VoIP), available at 773 http://www.bundesnetzagentur.de/media/archive/3186.pdf", 774 September 2005. 776 [Law2] "70. Konferenz der Datenschutzbeauftragten des Bundes und 777 der Laender: Entschliessung Telefonieren mit 778 Internettechnologie (Voice over IP - VoIP), available at 779 http://www.datenschutzzentrum.de/material/themen/press 780 e/20051028-dsbk-voip.htm", Oktober 2005. 782 [Law3] "Working Party 29 Opinion 2/2006 on privacy issues related 783 to the provision of email screening services, WP 118, 784 available at http://ec.europa.eu/justice_home/fsj/privacy/ 785 docs/wpdocs/2006/wp118_en.pdf", February 2006. 787 Appendix A. Outside the Scope 789 We consider the following aspects outside the scope of this document: 791 o Mechanisms to publish SPIT causing parties on the Internet, i.e., 792 information about domains that create SPIT. 793 o Determining the source of unwanted traffic in real-time. 794 o Pushing packet filters and authorization policies towards the SPIT 795 sending domain. 797 Authors' Addresses 799 Hannes Tschofenig 800 Nokia Siemens Networks 801 Otto-Hahn-Ring 6 802 Munich, Bavaria 81739 803 Germany 805 Email: Hannes.Tschofenig@nsn.com 806 URI: http://www.tschofenig.com 808 Henning Schulzrinne 809 Columbia University 810 Department of Computer Science 811 450 Computer Science Building 812 New York, NY 10027 813 US 815 Phone: +1 212 939 7004 816 Email: hgs@cs.columbia.edu 817 URI: http://www.cs.columbia.edu 818 Dan Wing 819 Cisco Systems 821 Phone: 822 Email: dwing@cisco.com 824 Jonathan Rosenberg 825 Cisco Systems 826 600 Lanidex Plaza 827 Parsippany, New York 07054 828 USA 830 Email: jdrosen@cisco.com 831 URI: http://www.jdrosen.net 833 David Schwartz 834 Kayote Networks 835 Malcha Technology Park 836 Jerusalem 96951 837 Israel 839 Email: david.schwartz@kayote.com 841 Full Copyright Statement 843 Copyright (C) The IETF Trust (2007). 845 This document is subject to the rights, licenses and restrictions 846 contained in BCP 78, and except as set forth therein, the authors 847 retain all their rights. 849 This document and the information contained herein are provided on an 850 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 851 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 852 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 853 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 854 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 855 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 857 Intellectual Property 859 The IETF takes no position regarding the validity or scope of any 860 Intellectual Property Rights or other rights that might be claimed to 861 pertain to the implementation or use of the technology described in 862 this document or the extent to which any license under such rights 863 might or might not be available; nor does it represent that it has 864 made any independent effort to identify any such rights. Information 865 on the procedures with respect to rights in RFC documents can be 866 found in BCP 78 and BCP 79. 868 Copies of IPR disclosures made to the IETF Secretariat and any 869 assurances of licenses to be made available, or the result of an 870 attempt made to obtain a general license or permission for the use of 871 such proprietary rights by implementers or users of this 872 specification can be obtained from the IETF on-line IPR repository at 873 http://www.ietf.org/ipr. 875 The IETF invites any interested party to bring to its attention any 876 copyrights, patents or patent applications, or other proprietary 877 rights that may cover technology that may be required to implement 878 this standard. Please address the information to the IETF at 879 ietf-ipr@ietf.org. 881 Acknowledgment 883 Funding for the RFC Editor function is provided by the IETF 884 Administrative Support Activity (IASA).