idnits 2.17.00 (12 Aug 2021) /tmp/idnits6715/draft-tschofenig-sipping-framework-spit-reduction-00.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 821. 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 are 4 instances of too long lines in the document, the longest one being 6 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 (June 14, 2007) is 5455 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.froment-sipping-spit-authz-policies' is defined on line 658, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sip-consent-framework' is defined on line 678, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: draft-ietf-simple-xcap has been published as RFC 4825 == 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 Summary: 4 errors (**), 0 flaws (~~), 13 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: Standards Track H. Schulzrinne 5 Expires: December 16, 2007 Columbia University 6 D. Wing 7 J. Rosenberg 8 Cisco Systems 9 D. Schwartz 10 Kayote Networks 11 June 14, 2007 13 A Framework for Reducing Spam for Internet Telephony 14 draft-tschofenig-sipping-framework-spit-reduction-00.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on December 16, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 Spam, defined as sending unsolicited messages to someone in bulk, 48 might be a problem on SIP open-wide deployed networks. A number of 49 solutions have been proposed for dealing with Spam for Internet 50 Telephony (SPIT), for example, content filtering, black lists, white 51 lists, consent-based communication, reputation systems, address 52 obfuscation, limited use addresses, turing tests, computational 53 puzzles, payments at risk, circles of trust, and many others. This 54 document describes the big picture that illustrates how the different 55 building blocks fit together and can be deployabled incrementally. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Communication Patterns and User Groups . . . . . . . . . . . . 6 63 4.1. Closed Groups . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. Semi-Open Groups . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Open Groups . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 4.5. Usability . . . . . . . . . . . . . . . . . . . . . . . . 8 68 5. Protocol Interactions . . . . . . . . . . . . . . . . . . . . 9 69 5.1. End Host based Rule Enforcement . . . . . . . . . . . . . 9 70 5.2. Rule Enforcement via a Trusted Intermediary . . . . . . . 9 71 5.3. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 72 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 12 73 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 75 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Appendix A. Outside the Scope . . . . . . . . . . . . . . . . . . 17 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Intellectual Property and Copyright Statements . . . . . . . . . . 19 83 1. Introduction 85 The problem of Spam for Internet Telephony (SPIT) is an imminent 86 challenge and only the combination of several techniques can provide 87 a framework for dealing with unwanted communication attempts. 89 [I-D.ietf-sipping-spam] provides four core recommendations that need 90 to be considered for a SPIT solution, namely 92 o Strong Identity 93 o White Lists 94 o Solve the Introduction Problem 95 o Don't Wait Until its Too Late 97 This document illustrates how existing building blocks can be put 98 together to form a solution to deal with SPIT. New building blocks 99 can be added to provide more efficient SPIT handling, since there is 100 no single solution that provides 100 % protection. 102 The main purpose of this document is largely to define a model of 103 internal device processing, protocol interfaces, and terminology, 104 which define a way in which we can plug-in future protocols. We 105 focus only on the most important solution components and consider 106 many other aspects either outside the scope of this work (see 107 Appendix A) and postpone them for future work. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 3. Framework 117 The framework considered in this document assumes that an end user 118 uploads authorization policies to a SIP proxy of its VoIP provider. 119 That VoIP provider enforces those authorization policies. This 120 separation allows the end user to offload some authorization 121 decisions to the VoIP provider which can save bandwidth and activity 122 on the SIP UA. 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, uploads authorization policies. 127 These policies are processed by corresponding module within the SIP 128 proxy, called Authorization Engine, that interacts with the message 129 routing functionality. A part of the rule set might, however, also 130 be created automatically as part of interactive interactions (e.g., 131 monitoring ongoing communication attempts). 133 +---------------------------------------------------------+ 134 | Authorization | 135 | re-route Policy | 136 | ^ (implicit) | 137 | o +#######+ | 138 | o # # | 139 | +---o----------#-------#--+ | 140 | | o # # | | 141 +--------+ | | o Proxy # # | | 142 | | | | o # # |<*******************+ | 143 | Sender |<***>|+-------+ v # | * | 144 | | | ||Msg. | +-----------+| Authorization * | 145 +--------+ | ||Routing| | Authz. || Policy (explicit) * | 146 ^ o | ||Engine |<->| Engine |<#################+ * | 147 * o | |+-------+ +-----------+| # * | 148 * o | +-^--*--^-----------------+ # v | 149 * o | o * o +-------------+ | 150 * o | o * o | | | 151 * +oooo|oooo+ * +ooooooooooooooooooooooooooooo>| Recipient | | 152 +**************************************************>| | | 153 | +-------------+ | 154 | | 155 | | 156 +-------------------Domain Boundary-----------------------+ 158 Legend: 160 oooo: SIP Message Interaction 161 ****: Protocol Interaction for Authorizing the Message Sender 162 ####: Management of Authorization Policies 164 Figure 1: Overview 166 Assume that an arbitrary sender transmits a message towards the 167 recipients URI that finally hits the SIP proxy on the recipients 168 side. Information provided within that message are used as input to 169 the rule evaluation. Any part of the message may serve as input to 170 the evaluation process but for practical reasons only a few selected 171 fields do most of the work. In this document, we argue that the 172 authenticated identity of the sender is the most valuable information 173 item. In the future, when standardization progresses then, for 174 example, reputation information obtained from social networks may 175 offer additional input to the authorization process. The protocol 176 interaction for authorizing the message sender refers to the ability 177 of the recipient or the proxy to interact with the sender to request 178 authorization. The request for authorization is a pull model whereby 179 the proxy or the recipient challenges the sender (e.g., via hash cash 180 [I-D.jennings-sip-hashcash], or SIP payment 181 [I-D.jennings-sipping-pay]) for authorization. SIP Identity on the 182 other hand realizes as push model whereby authentication information 183 is pushed towards the recipient. 185 Figure 2 shows this integration step. The conditions part of the 186 rule offer a mechanisms to incrementally extend the overall framework 187 with new SPIT prevention solution components. Depending on the rule 188 evaluation the message may be rerouted to another entity, such as an 189 answering machine, to the recipient, rejected or other actions are 190 triggered. The latter aspect is particularly interesting since it 191 allows further solution components to be executed. For example, a 192 permission request as part of the consent framework. 194 SIP message with 195 authenticated 196 identity +---------------+ ^ 197 -------------->| | | 198 Additional | |-----------+ 199 Msg fields | Authorization | re-routed 200 -------------->| Engine | 201 Other SPIT | |----------------> 202 Prevention | | forwarded to 203 Components | | original 204 -------------->+---------------+ recipient 205 | | 206 | | 207 <-----------+ +----------->|| 208 politely blocked blocked 210 Figure 2: Message Filtering and Routing 212 Note that some traffic analysis and consequently some form of content 213 filtering (e.g., of MESSAGEs) can be applied locally within the VoIP 214 provider's domain also under the control of the end user. For 215 example, a user that does not want content filtering to impact 216 message handling would therefore not utilize this functionality. 218 In a minimalistic SPIT framework only authenticated identities in 219 combination with authorization policies are used. This should serve 220 as a starting point for future work. 222 Authenticated Identities: 224 SIP Identity [RFC4474] is assumed to be used to provide the 225 receiver of a communication attempt with the authenticated 226 identity. SIP Identity is a reasonable simple specification and 227 does not rely on a huge amount of infrastructure support. 228 Note: SIP Identity is comparable to DKIM 229 [I-D.ietf-dkim-overview] used for associating a "responsible" 230 identity with an email message and provides a means of 231 verifying that the association is legitimate. 233 Authorization Policies: 235 When the white lists are stored and managed only at the end host 236 then the authorization policies and the protocol to modify the 237 policies do not need to be standardized since they are purely 238 implementation specific details. Even if the authorization 239 policies are managed centrally or some amount of policy 240 enforcement is done by trusted intermediaries then still there 241 might not be a need to standardize an authorization policy 242 language if the policies can be modified via a webpage. This type 243 of policy handling is done in many cases today already for various 244 applications. 246 Unfortunately, this approach tends to become cumbersome to manage 247 for end users and therefore it is useful to hide a lot of policy 248 details from the end user itself and to make use of context 249 information, for example, address books and authorization policies 250 available already created for presence based systems. 252 In some cases the above-described approach is not sufficient 253 whereby it is necessary to define a standardized protocol, for 254 example, if policies are used by different entities, created and 255 modified in an automatic way and when multiple entities manipulate 256 policies (potentially on behalf of the person affected by the 257 policies). 259 The white list needs to be created somehow and hence there is an 260 introduction problem. Section 4 discusses this aspect in more 261 details. 263 4. Communication Patterns and User Groups 265 When communication takes place then at least three types of groups 266 can be identified. 268 4.1. Closed Groups 270 People in this group communicate only with the peers in their group. 271 They do not appreciate communication attempts from outside. 272 Communication is possible only for people within this list. Here is 273 an example of a closed group: Consider parents that do not want their 274 children from getting contaced by strangers. Hence, they may create 275 a white list containing the identifies of known friends, parents and 276 other relatives on behalf of their kids. 278 The usage of authorization policies for usage with Closed Groups is 279 straight forward. 281 4.2. Semi-Open Groups 283 In a semi-open environment all members of the same group are allowed 284 to get in contact with everyone else (e.g., for example in a company 285 environment). For members outside the company the communication 286 patters depend on the role of the person (e.g., standardization 287 people, sales people, etc.) and on the work style of the person. 289 For this category we distinguish a number of (non-spam) message 290 sources based on their characteristics: 292 o "friends" or "acquaintances", i.e., those we have communicated 293 with before. 294 o strangers, divided into 'interesting' and 'uninteresting'. The 295 latter are messages from people that someone does not care to have 296 a conversation with or respond to, at least at that particular 297 moment. 299 Strangers can be defined by individual names or whole domains. A 300 special class of 'stranger' messages are transaction-related 301 communications, such as Instant Messaging or automated calls from an 302 airline or shipping company. 304 The usage of authorization policies for usage with Semi-Open Groups 305 can be considered manageable. 307 In the PSTN a certain amount of protection against unwanted calls is 308 provided due to costs for phone calls. With almost free calls (or 309 instant messages) it might be necessary to abandon the idea of 310 allowing end-to-end real-time message delivery in all cases in order 311 to avoid the alerting the user. 313 4.3. Open Groups 315 People in this type of group are not allowed to limit communication 316 attempts. Help desks, certain people in governmental agencies, 317 banks, insurance companies, etc. 319 For Open Groups the situation is more complicated. Consider a person 320 working on a customer support helpdesk. Ideally, they would like to 321 receive only calls from friendly customers (although the motivation 322 for calling is most likely a problem) and the topic of the calls only 323 relates to problems they are able to solve. Without listening to the 324 caller they will have a hard time to know whether the call could be 325 classified as SPIT. Many SPIT prevention techniques might not be 326 applicable since blocking callers is likely not possible and applying 327 other techniques, such as turing tests, might not be ideal in an case 328 of Open Groups. 330 4.4. Summary 332 Based on the discussions regarding communication patters and groups 333 the following observations can be made: 335 o A single person very likely has many roles and they may have an 336 impact on the communication patterns. 337 For example, consider a person who is working in a company but 338 also want to be available for family members. 339 o The context in which a person is may change at any time. For 340 example, a person might be available for family members while at 341 work except during an important meeting where communication 342 attempts may be rejected. Switching a context has an impact for 343 reachability and the means for communicating with a specific 344 recipient, based on enabled rule sets. 346 From an authorization policy point of view it is important to be able 347 to express a sphere, i.e., the state a user is in and to switch 348 between different spheres easily by thereby switching to a different 349 rule set. 351 4.5. Usability 353 An important aspect in the usage of authorization policies is to 354 assist the user when creating policies. Ideally, the policies should 355 be established automatically. Below, there are a couple of examples 356 to illustrate the idea given that these aspects are largely 357 implementation issues: 359 o It must be possible for the proxy to automatically add addresses 360 on outbound messages and calls to the rule set. This approach is 361 similar to stateful packet filtering firewalls where outbound 362 packets establish state at the firewall to allow inbound packets 363 to traverse it again. 364 o Already available information in the address book can be used for 365 building the policy rules there is quite likely already a 366 relationship available with these persons existent. 367 o A large amount of email is non-personal, automated communication, 368 such as newsletters, confirmations and legitimate advertisements. 369 These are often tagged as spam by content filters. This type of 370 correspondence is usually initiated by a transaction over the web, 371 such as a purchase or signing up for a service. 372 [I-D.shacham-http-corr-uris], for example, defines an HTTP header 373 for conveying future correspondence addresses that can be 374 integrated in the rule set. 376 5. Protocol Interactions 378 This section describes the necessary building blocks that are 379 necessary to tie the framework together. We will describe two 380 different environments, namely one where rule enforcement happens at 381 the end host and another one where a trusted network intermediary 382 performs the actions. 384 5.1. End Host based Rule Enforcement 386 o SIP Identity [RFC4474] is mandatory to implement at the end host 387 and used to determine the authenticated identity of the sending 388 side. 389 o Authorization policies are purely implementation specific matter. 391 Since a purely end host based rule enforcement suffers from a number 392 of drawbacks, rule enforcement by a trusted intermediary is also 393 offered. 395 5.2. Rule Enforcement via a Trusted Intermediary 397 o SIP Identity [RFC4474] is mandatory to implement at the trusted 398 intermediary (e.g., the immediate VoIP provider) and it determines 399 the authenticated identity of the sending side. 400 o Authorization Policies based on the Common Policy framework 401 [RFC4745], as extended in [I-D.tschofenig-sipping-spit-policy] for 402 the purpose of SPIT prevention, are mandatory to implement at the 403 end host side and at the trusted intermediary. The implementation 404 of the rule evaluation engine might only be necessary on the 405 trusted VoIP proxy. Harmonization with the work done for presence 406 authorization [I-D.ietf-simple-presence-rules], which is based on 407 Common Policy [RFC4745], can be accomplished and is highly 408 desirable. 409 o XML Configuration Access Protocol (XCAP) [I-D.ietf-simple-xcap] is 410 used to create, modify and delete authorization policies and is 411 mandatory to implement at the end host side and at the trusted 412 intermediary. 414 5.3. Incremental Deployment 416 An important property is incremental deployment of additional 417 solution components that can be added and used when they become 418 available. This section aims to illustrate how the extensibility is 419 accomplished, based on an example. 421 Consider a VoIP provider that provides authorization policies that 422 provide the following functionality equivalent to the Common Policy 423 framework, i.e., identity-based, sphere and validity based conditions 424 initially. For actions only 'redirection' and 'blocking' is 425 provided. In our example we give this basic functionality the AUID 426 'new-spit-policy-example' with the namespace 427 'urn:ietf:params:xml:ns:new-spit-policy-example'. 429 When a client queries the capabilities of a SIP proxy in the VoIP 430 providers network using XCAP the following exchange may take place. 432 GET /xcap-caps/global/index HTTP/1.1 433 Host: xcap.example.com 435 Initial XCAP Query for Capabilities 437 HTTP/1.1 200 OK 438 Etag: "wwhha" 439 Content-Type: application/xcap-caps+xml 441 442 443 444 new-spit-policy-example 445 xcap-caps 446 447 448 urn:ietf:params:xml:ns:new-spit-policy-example 449 urn:ietf:params:xml:ns:common-policy 450 451 452 Initial XCAP Response with the supported Capabilities 454 As shown in the example above, Common Policy and the example SPIT 455 extension is implemented and the client can upload rules according to 456 the definition of the rule set functionality. 458 Later, when the VoIP provider updates the functionality of 459 authorization policies as more sophisticated mechanisms become 460 available and get implemented the functionality of the authorization 461 policy engine is enhanced with, for example, hashcash and the ability 462 to perform statistical analysis of signaling message. The latter 463 functionality comes with the ability to mark messages are Spam and 464 the ability for end users to enable/disable this functionality. We 465 use the AUIDs 'hashcash', 'statistical-analysis' with the namespace 466 'urn:ietf:params:xml:ns:hashcash' and 467 'urn:ietf:params:xml:ns:statistical-analysis', respectively. 469 A end user could now make use of these new functions and a capability 470 query of the SIP proxy would provide the following response. 472 GET /xcap-caps/global/index HTTP/1.1 473 Host: xcap.example.com 475 Second XCAP Query for Capabilities 477 HTTP/1.1 200 OK 478 Etag: "wwhha" 479 Content-Type: application/xcap-caps+xml 481 482 483 484 new-spit-policy-example 485 xcap-caps 486 hashcash 487 statistical-analysis 488 489 490 urn:ietf:params:xml:ns:new-spit-policy-example 491 urn:ietf:params:xml:ns:common-policy 492 urn:ietf:params:xml:ns:hashcash 493 urn:ietf:params:xml:ns:statistical-analysis 494 495 497 Second XCAP Response with the supported Capabilities 499 New SPIT handling functionality may extend condition, actions and/or 500 transformation elements of a rule. 502 6. Privacy Considerations 504 This document does not propose to distribute the user's authorization 505 policies to other VoIP providers nor is the configuration of policies 506 at SIP proxies other than the trusted user's VoIP provider necessary. 507 Furthemore, if blocking or influencing of the message processing is 508 executed by the VoIP provider then they have to be explicitly enabled 509 by the end user. Blocking of messages, even if it is based on 510 "super-clever" machine learning techniques often introduces 511 unpredictability. 513 Legal norms from fields of law can take regulative effects in the 514 context of SPIT processing, such as constitutional law, data 515 protection law, telecommunication law, teleservices law, criminal 516 law, and possibly administrative law. See, for example, [Law1], 517 [Law2] and [Law3]. For example, it is mandatory to pass full control 518 of SPIT filtering to the end user, as this minimises legal problems. 520 An overview about regulatory aspects can be found in [Spit-AL]. 522 7. Example 524 This section shows an example whereby we consider a user 525 Bob@company-example.com that writes (most likely via a nice user 526 interface) the following policies. We use a high-level language to 527 show the main idea of the policies. 529 RULE 1: 530 IF identity=alice@foo.example.com THEN ACCEPT 531 IF identity=tony@bar.example.com THEN ACCEPT 533 RULE 2: 534 IF domain=company-example.com THEN ACCEPT 536 RULE 3: 537 IF unauthenticated THEN 538 EXECUTE hashcast 539 REDIRECT sip:voicebox@company-example.com 541 Example of Bob's Rule Set 543 At some point in time Bob uploads his policies to the SIP proxy at 544 his VoIP providers SIP proxy. 546 PUT 547 /spit-services/users/sip:bob@company-example.com/index/~~/spit-services/ 548 service%5b@uri=%22sip:good-friends@example.com%22%5d 549 HTTP/1.1 550 Content-Type:application/spit+xml 551 Host: proxy.home-example.com 553 <<<< Policies go in here. >>>> 555 Uploading Policies using XCAP 557 When BoB receives a call from his friends, alice@foo.example and 558 tony@bar.example.com, then the call is forwarded without any further 559 checks based on Rule 1. The rules assume that the authenticated 560 identity of the caller has been verified. 562 When Bob receives a call from a co-worker, 563 Charlie@company-example.com, Rule 2 is applied since the domain part 564 in the rule matches the domain part of Charlie's identity. 566 Now, when Bob receives a contact from an unknwon user, called Mallice 567 in this example. Rule 3 indicates that an extended return- 568 routability test using hashcash is used with the call being 569 redirected to Bob's voicebox afterwards. This exchange is shown in 570 the figure below. 572 UA Proxy Bob's 573 Malice Voicebox 574 | INVITE | | 575 |------------------------->|Puzzle: work=15; | 576 | |pre="VgVGYixbRg0mdSwTY3YIfCBuAAA="; | 577 | 419 with Puzzle |image="NhhMQ2l7SE0VBmZFKksUC19ia04="; | 578 | |value=160 | 579 |<-------------------------| | 580 | | | 581 | ACK | | 582 |------------------------->| | 583 | |Puzzle: work=0; | 584 | |pre="VgVGYixbRg0mdSwTY3YIfCBuYmg="; | 585 | |image="NhhMQ2l7SE0VBmZFKksUC19ia04=" | 586 | INVITE with Solution |value=160 | 587 |------------------------->| INVITE | 588 | |------------------------------------->| 589 | | | 590 | | 180 Ringing | 591 | 180 Ringing |<-------------------------------------| 592 |<-------------------------| | 593 | | 200 OK | 594 | 200 OK |<-------------------------------------| 595 |<-------------------------| | 596 | | ACK | 597 |---------------------------------------------------------------->| 598 | | | 600 Example Exchange: Malice contacts Bob 602 8. Security Considerations 604 This document aims to describe a framework for addressing Spam for 605 Internet Telephony (SPIT) in order to make it simple for users to 606 influence the behavior of SIP message routing with an emphasis on 607 SPIT prevention. 609 The framework relies on three building blocks, namely SIP Identity, 610 authorization policies based on Common Policy and Presence 611 Authorization Policy, and XCAP. 613 As a high-level overview, the framework allows the user to control 614 end-to-end connectivity at the SIP message routing level whereby the 615 glue that lets all parts fit together is based on authorization 616 policies. Several other solution components can be developed 617 independently and can be plugged into the framework as soon as 618 available. 620 It must be avoided to introduce Denial of Service attacks against the 621 recipient by misguiding him or her to install authorization policies 622 that allow senders to bypass the policies although that was never 623 intended by the recipient. Additionally, it must not be possible by 624 extensions to the authorization policy framework to create policies 625 to block legitimate senders or to stall the processing of the 626 authorization policy engine. 628 9. Acknowledgments 630 We would like to thank Jeremy Barkan, Dan York, Alexey Melnikov, 631 Thomas Schreck, Eva Leppanen, Cullen Jennings, Marit Hansen, and 632 Markus Hansen for their review comments. 634 10. References 636 10.1. Normative References 638 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 639 Requirement Levels", March 1997. 641 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 642 Authenticated Identity Management in the Session 643 Initiation Protocol (SIP)", RFC 4474, August 2006. 645 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 646 Polk, J., and J. Rosenberg, "Common Policy: A Document 647 Format for Expressing Privacy Preferences", RFC 4745, 648 February 2007. 650 [I-D.ietf-simple-xcap] 651 Rosenberg, J., "The Extensible Markup Language (XML) 652 Configuration Access Protocol (XCAP)", 653 draft-ietf-simple-xcap-12 (work in progress), 654 October 2006. 656 10.2. Informative References 658 [I-D.froment-sipping-spit-authz-policies] 659 Froment, T., "Authorization Policies for Preventing SPIT", 660 draft-froment-sipping-spit-authz-policies-02 (work in 661 progress), February 2007. 663 [I-D.ietf-sipping-spam] 664 Jennings, C. and J. Rosenberg, "The Session Initiation 665 Protocol (SIP) and Spam", draft-ietf-sipping-spam-04 (work 666 in progress), February 2007. 668 [I-D.ietf-simple-presence-rules] 669 Rosenberg, J., "Presence Authorization Rules", 670 draft-ietf-simple-presence-rules-09 (work in progress), 671 March 2007. 673 [I-D.jennings-sip-hashcash] 674 Jennings, C., "Computational Puzzles for SPAM Reduction in 675 SIP", draft-jennings-sip-hashcash-05 (work in progress), 676 June 2007. 678 [I-D.ietf-sip-consent-framework] 679 Rosenberg, J., "A Framework for Consent-Based 680 Communications in the Session Initiation Protocol (SIP)", 681 draft-ietf-sip-consent-framework-01 (work in progress), 682 November 2006. 684 [I-D.ietf-dkim-overview] 685 Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 686 Identified Mail (DKIM) Message Signing Service Overview", 687 draft-ietf-dkim-overview-05 (work in progress), June 2007. 689 [I-D.tschofenig-sipping-spit-policy] 690 Tschofenig, H., "Anti-SPIT : A Document Format for 691 Expressing Anti-SPIT Authorization Policies", 692 draft-tschofenig-sipping-spit-policy-00 (work in 693 progress), February 2007. 695 [I-D.shacham-http-corr-uris] 696 Shacham, R. and H. Schulzrinne, "HTTP Header for Future 697 Correspondence Addresses", draft-shacham-http-corr-uris-00 698 (work in progress), May 2007. 700 [I-D.jennings-sipping-pay] 701 Jennings, C., "Payment for Services in Session Initiation 702 Protocol (SIP)", draft-jennings-sipping-pay-05 (work in 703 progress), October 2006. 705 [Spit-AL] Hansen, M., Hansen, M., Moeller, J., Rohwer, T., Tolkmitt, 706 C., and H. Waack, "Developing a Legally Compliant 707 Reachability Management System as a Countermeasure against 708 SPIT, Third Annual VoIP Security Workshop, Berlin, 709 available at 710 https://tepin.aiki.de/blog/uploads/spit-al.pdf", 711 June 2006. 713 [Law1] "Bundesnetzagentur: Eckpunkte der regulatorischen 714 Behandlung von Voice over IP (VoIP), available at 715 http://www.bundesnetzagentur.de/media/archive/3186.pdf", 716 September 2005. 718 [Law2] "70. Konferenz der Datenschutzbeauftragten des Bundes und 719 der Laender: Entschliessung Telefonieren mit 720 Internettechnologie (Voice over IP - VoIP), available at 721 http://www.datenschutzzentrum.de/material/themen/press 722 e/20051028-dsbk-voip.htm", Oktober 2005. 724 [Law3] "Working Party 29 Opinion 2/2006 on privacy issues related 725 to the provision of email screening services, WP 118, 726 available at http://ec.europa.eu/justice_home/fsj/privacy/ 727 docs/wpdocs/2006/wp118_en.pdf", February 2006. 729 Appendix A. Outside the Scope 731 We consider the following aspects outside the scope of this document: 733 o Mechanisms to publish SPIT causing parties on the Internet, i.e., 734 information about domains that create SPIT. 735 o Determining the source of unwanted traffic in real-time. 736 o Pushing packet filters and authorization policies towards the SPIT 737 sending domain. 739 Authors' Addresses 741 Hannes Tschofenig 742 Nokia Siemens Networks 743 Otto-Hahn-Ring 6 744 Munich, Bavaria 81739 745 Germany 747 Email: Hannes.Tschofenig@nsn.com 748 URI: http://www.tschofenig.com 749 Henning Schulzrinne 750 Columbia University 751 Department of Computer Science 752 450 Computer Science Building 753 New York, NY 10027 754 US 756 Phone: +1 212 939 7004 757 Email: hgs+ecrit@cs.columbia.edu 758 URI: http://www.cs.columbia.edu 760 Dan Wing 761 Cisco Systems 763 Phone: 764 Email: dwing@cisco.com 766 Jonathan Rosenberg 767 Cisco Systems 768 600 Lanidex Plaza 769 Parsippany, New York 07054 770 USA 772 Email: jdrosen@cisco.com 773 URI: http://www.jdrosen.net 775 David Schwartz 776 Kayote Networks 777 Malcha Technology Park 778 Jerusalem 96951 779 Israel 781 Email: david.schwartz@kayote.com 783 Full Copyright Statement 785 Copyright (C) The IETF Trust (2007). 787 This document is subject to the rights, licenses and restrictions 788 contained in BCP 78, and except as set forth therein, the authors 789 retain all their rights. 791 This document and the information contained herein are provided on an 792 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 793 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 794 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 795 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 796 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 797 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 799 Intellectual Property 801 The IETF takes no position regarding the validity or scope of any 802 Intellectual Property Rights or other rights that might be claimed to 803 pertain to the implementation or use of the technology described in 804 this document or the extent to which any license under such rights 805 might or might not be available; nor does it represent that it has 806 made any independent effort to identify any such rights. Information 807 on the procedures with respect to rights in RFC documents can be 808 found in BCP 78 and BCP 79. 810 Copies of IPR disclosures made to the IETF Secretariat and any 811 assurances of licenses to be made available, or the result of an 812 attempt made to obtain a general license or permission for the use of 813 such proprietary rights by implementers or users of this 814 specification can be obtained from the IETF on-line IPR repository at 815 http://www.ietf.org/ipr. 817 The IETF invites any interested party to bring to its attention any 818 copyrights, patents or patent applications, or other proprietary 819 rights that may cover technology that may be required to implement 820 this standard. Please address the information to the IETF at 821 ietf-ipr@ietf.org. 823 Acknowledgment 825 Funding for the RFC Editor function is provided by the IETF 826 Administrative Support Activity (IASA).