idnits 2.17.1 draft-niccolini-sipping-spitstop-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 745. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 756. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 763. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 769. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 15, 2008) is 5913 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 ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-tschofenig-sipping-framework-spit-reduction-02 == Outdated reference: A later version (-03) exists of draft-tschofenig-sipping-spit-policy-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group S. Niccolini 3 Internet-Draft J. Quittek 4 Intended status: Informational J. Seedorf 5 Expires: August 18, 2008 NEC 6 February 15, 2008 8 Signaling TO Prevent SPIT (SPITSTOP) Reference Scenario 9 draft-niccolini-sipping-spitstop-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 18, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This memo discusses the need for standards that support SPam over 43 Internet Telephony (SPIT) prevention applications. After explaining 44 the general need for SPIT prevention applications the memo provides a 45 reference scenario for potential communication between entities that 46 may be involved in SPIT prevention. Within this scenario the need 47 for standardizing communication is analyzed for each pair of 48 communicating entities. The analysis is intended to serve as a 49 starting point for discussing the requirements for signaling 50 standards as well as for architectural considerations, that support 51 SPIT prevention applications. 53 This memo is not intended to suggest any solution of SPIT signaling 54 issues. Such work, if necessary at all, should be object of separate 55 documents. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. The SPIT Threat . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. Communication Need for SPIT Prevention . . . . . . . . . . 4 63 2. Reference Scenario . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Signaling Interfaces Considerations . . . . . . . . . . . . . 8 66 3.1. Interfaces on the Signaling Path . . . . . . . . . . . . . 8 67 3.1.1. Downstream . . . . . . . . . . . . . . . . . . . . . . 8 68 3.1.2. Upstream . . . . . . . . . . . . . . . . . . . . . . . 10 69 3.2. Off-Path Interfaces between Proxy Servers . . . . . . . . 12 70 3.3. Interfaces to Special SPIT Prevention Entities . . . . . . 13 72 4. Need for Standardization . . . . . . . . . . . . . . . . . . . 14 73 4.1. Preliminary Protocol Considerations . . . . . . . . . . . 14 75 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 81 8. Informative References . . . . . . . . . . . . . . . . . . . . 16 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 84 Intellectual Property and Copyright Statements . . . . . . . . . . 18 86 1. Introduction 88 Email is an essential mean for world-wide communication. The 89 openness of the Internet make use of email easy but also makes it 90 easy to mis-use it, particular to annoy users with spam email. 91 Today, there is more spam email transmitted by the public Internet 92 than regular email. 94 Internet telephony is on its way to replace the traditional circuit- 95 switched telephony. There is a strong concern that this migration to 96 the open Internet will result in Spam over Internet Telephony (SPIT) 97 that potentially will be annoy the users even more than spam email 98 does today. If there are more SPIT calls than regular calls in the 99 telephony world, then phones will ring all day making it hard to use 100 this medium in a convenient and productive way. 102 This memo discusses the need for producing standards that help 103 preventing SPIT in the future. Although SPIT is not an actual 104 problem today, it has a big potential to become one very soon. At 105 this point in time it will be good to be prepared and have technology 106 already available that protects users from SPIT. 108 1.1. The SPIT Threat 110 Most of the spam emails are generated by so-called bot nets. Bot 111 nets are networks of hosts that have been invaded by a spammer in 112 order to use them for sending spam email without the knowledge of or 113 admission by the regular administrators of these hosts. Bot nets can 114 easily be used for initiating spam voice calls instead of or in 115 addition to sending spam email. 117 Today, there is already voice spam in the switched telephony network. 118 Many households in Europe receive between 1 and 10 automated spam 119 calls per month. During such a call, a prerecorded messages is 120 played to the callee without supporting any interaction. However, 121 these calls create significant cost for the caller, at least if they 122 are made in numbers of thousands or hundred thousands. 124 With the ongoing migration from traditional connection-switched 125 telephony to packet-switched Internet telephony the cost of spam 126 calls will drop drastically. The infrastructure for generating Spam 127 over Internet Telephony (SPIT) is already there in form of the 128 existing bot nets. A recent study [RFC5039] estimated that the cost 129 per delivery of SPIT call will be up to four order of magnitude 130 cheaper than the costs per delivery of spam over circuit-switched 131 telephony. This is expected to cause a flood of SPIT calls as soon 132 as Internet telephony becomes the dominating telephony technology. 134 For dealing with this problem, particularly for preventing unwanted 135 SPIT, not all methods that are used today for blocking spam email can 136 be applied. Particularly, content checking, that is a basic method 137 for detecting email spam, is not applicable, because content of a 138 call is not available for checking before the phone rings. And 139 stopping the phone from ringing for spam calls is one of the major 140 goals of SPIT prevention. Therefore, further methods are needed. An 141 overview of methods that are currently available for SPIT prevention 142 is given in [RFC5039]. 144 The number of SPIT prevention methods listed there is quite large. 145 Still, it is not considered to be a complete list or a list that is 146 exhaustive enough for preventing SPIT sufficiently. On the contrary, 147 this list shows that there are still a lot of opportunities left for 148 SPIT generators to place SPIT calls successfully. 150 1.2. Communication Need for SPIT Prevention 152 An important aspect in this context has not been investigated in 153 detail yet. It is sharing of information between entities that are 154 involved in preventing SPIT. They may have a need to exchange 155 information related to SPIT. The range of information to be 156 exchanged includes information about 158 o SPIT events that actually occurred, 159 o indicators concerning callers to be sources of SPIT, 160 o indicators concerning concrete calls to be SPIT, 161 o etc. 163 This memo investigates the need of communication between entities 164 involved in SPIT prevention and the need of standards for this 165 communication. For this purpose, a reference scenario is defined in 166 Section 2 that serves for identifying which communications interfaces 167 may be required for sharing SPIT-related information between involved 168 entities. Based on this scenario, requirements for individual 169 interfaces are discussed in Section 3. 171 Currently, the requirements are stated on a high level. Future 172 revisions of this memo may elaborate the requirements in more detail. 173 Which (kind of) communication protocol should be chosen for meeting 174 the requirements is not subject of this memo. 176 However, this memo is supposed to stimulate discussion on the need of 177 standardization work in this area. The standardization work should 178 both identify the reference architecture, the best suited protocols 179 for such information sharing at each interface and if extensions to 180 such protocols for the support of SPIT information sharing is needed. 181 If no suitable protocols matching the requirements for a particular 182 interface is found a suggestion for the design of a new protocol 183 suited to such information sharing should be initiated. 185 2. Reference Scenario 187 For our reference scenario we consider four kinds of communicating 188 entities: 190 o the caller User Agent (UA) that generates SPIT, 191 o Proxy Servers (PS) forwarding call signaling, 192 o specialized SPIT prevention entities, 193 o the callee User Agent (UA). 195 With the goal of avoiding that the callee's phone rings for SPIT 196 calls, SPIT prevention devices should detect a SPIT message already 197 based on the INVITE method that is sent in order to initiate the SPIT 198 call. This goal can only be achieved along the path the INVITE 199 message is forwarded from the caller towards the callee. This path 200 starts at the caller UA, then potentially includes a set of 201 forwarding PS, and terminates latest at the callee UA. 203 Please note that the described reference scenario can be easily 204 mapped to the framework overview described in 205 [I-D.tschofenig-sipping-framework-spit-reduction], the major 206 difference is that the framework discussed in such a draft takes into 207 account only one domain boundary while the reference scenario here 208 described is more general and assumes that interactions among 209 multiple domains could be used in order to allow distributed 210 decisions. 212 +--------+ 213 | | 214 | caller | 215 | UA | 216 | | 217 +--------+ |d ^ 218 # | ^ |o | 219 # | | |w |u 220 # | | |n |p 221 # -------(a) |s |s 222 # | | |t |t 223 # | | |r |r 224 (d) V v | (e) |e |e 225 +--------+ | +--------+ | +--------+ |a |a 226 | | | | | | | SPIT | |m |m 227 | Other |<---|----| Proxy |----|--->| Prev. | | | 228 | Proxy |----|--->| Server |<---|----| Entity | v | 229 | | | | | | | | 230 +--------+ +--------+ +--------+ 231 # | ^ 232 # | | 233 # | | 234 # -------(b) # S 235 # | | # I 236 # | | # P 237 (d) V v | (e) # 238 +--------+ | +--------+ | +--------+ # I 239 | | | | | | | SPIT | # N 240 | Other |<---|----| Proxy |----|--->| Prev. | # V 241 | Proxy |----|--->| Server |<---|----| Entity | # I 242 | | | | | | | | # T 243 +--------+ +--------+ +--------+ # E 244 # | ^ # 245 # | | # m 246 # | | # e 247 # -------(c) # t 248 # | | # h 249 # | | # o 250 V v | (f) # d 251 +--------+ | +--------+ # 252 | | | | SPIT | V 253 | callee |----|--->| Prev. | 254 | UA |<---|----| Entity | 255 | | | | | 256 +--------+ +--------+ 258 Figure 1: SPIT prevention reference scenario with two proxy servers 260 Entities on the path from caller to callee may share information 261 related to SPIT prevention. Related communication may happen already 262 before a certain INVITE methods is transmitted or it may be initiated 263 by this message. If this communication includes transmitting 264 information in the same direction as the INVITE message along the 265 path, then we talk about downstream communication. Transmitting 266 information in the opposite direction we call upstream communication. 268 The SPIT prevention reference scenario shown in Figure 1 contains a 269 caller UA, a callee UA and two PS on the path of the INVITE message 270 from caller UA to callee UA. This number of PS was chosen because it 271 contains exactly one instance of each pair of interacting kinds of 272 entities along the path of the INVITE message: 274 o at interface (a) the caller UA is interacting with a PS, 275 o at interface (b) two consecutive PS are interacting with each 276 other, 277 o at interface (c) a PS is interacting with the callee UA. 279 The number of two PS matched the common SIP signaling trapezoid. 280 However, any number of proxy servers greater than zero can be applied 281 to the scenario. If there is only one PS present, then the interface 282 (b) is not instantiated. If there are two or more PS on the path, 283 then interface (b) is used between each consecutive pair of them. In 284 general, the INVITE message could be sent directly from caller UA to 285 callee UA without involving any PS. A direct call would be possible 286 if the caller UA sends the INVITE directly to the callee UA, anyway 287 such IP address retrieval is prone to errors either because of 288 possible change of IP address during time of callee UA or because of 289 Network Address Translator along the path masking the real IP 290 address. The direct call case becomes even less relevant if the 291 callee UAs are configured to accept INVITEs only from their proxy 292 servers. For these reasons we decided not to include an interface 293 for direct communication between caller UA and callee UA in the 294 reference scenario. 296 Each proxy server on the signaling path of the INVITE message may 297 communicate with off-path entities in order to help the task of SPIT 298 identification and prevention. 300 These entities include one or more specific SPIT prevention entities 301 that are consulted by the proxy server using interface (e) in order 302 to get an indication or estimation of a given INVITE message to 303 belong to a SPIT call (e.g. using authorization policies ). 305 These entities also include one or more cooperating PS with which 306 information about SPIT calls (or call attempts) is shared using 307 interface (d) in order to improve the SPIT prevention accuracy. An 308 example for such a cooperation would be a set of PS in a single 309 administrative domain sharing information about known sources of SPIT 310 (federation of black listing services across PS). 312 The callee UA may also interact with a specific SPIT prevention 313 entity similar to the PS (e.g. a local one located near the user 314 agent in the access domain). Since in this case, the offered service 315 might be more personalized than in the case of the PS, we use a 316 different interface (f) for our reference model. This does not 317 preclude that instantiations of (e) and (f) may have identical 318 functions (e.g. using the same authorization policies language 319 [I-D.tschofenig-sipping-spit-policy]). 321 3. Signaling Interfaces Considerations 323 This section discusses the interactions between entities of the 324 reference scenario that is shown in Figure 1. The interfaces are 325 grouped into three sections. 327 1. The first one deals with interfaces (a), (b), and (c) which all 328 serve for exchanging information between consecutive entities 329 along the path of the INVITE message of a particular call (e.g. 330 spam scores or spam feedbacks with well defined semantics ). 331 2. Interface (d) has a similar function but is off-path and not 332 necessarily related to individual (SPIT) calls (e.g. black 333 listing services across PS). 334 3. Interfaces (e) and (f) are used by PS or the callee UA when they 335 need to decide whether or not to consider a particular call 336 request as SPIT (e.g. authorization policies). 338 3.1. Interfaces on the Signaling Path 340 At all three interfaces (a), (b), and (c) information may be 341 exchanged in upstream direction as well as in downstream direction. 343 3.1.1. Downstream 345 There are several considerations of downstream communication that 346 apply to all three interfaces. We first describe them before 347 pointing out differences between the three interfaces. 349 All Interfaces (a), (b), and (c) 351 Downstream information is sent along with an INVITE in order to 352 provide information about the INVITE to belong to a SPIT call 353 (e.g. indicate that a caller is exceeding a sending treshold, that 354 the caller did not pass a specific test like a CAPTCA test , 355 etc.). A sender or forwarder of an INVITE may, for example, want 356 to signal such information to the downstream entity (be it PS or 357 UA) but still not have sufficient certainty or not have legal 358 rights for blocking a SPIT call. 360 In any case, interface (a), (b), or (c) would allow to pass such 361 information further along the path of the INVITE. Even if such 362 information does not always lead to achieving a clear idea on the 363 nature of the requested call (e.g. the final decision is taken 364 only by downstream entities, like the UA), the transmitted 365 information can be recorded by the receivers of this information 366 and used for improving future judgments of call requests for SPIT 367 prevention. 369 In addition such interfaces would allow to pass statistics about 370 the recent behavior of the sender. An example of these statistics 371 would consist in the rate of (SPIT) calls initiated by the sender 372 during the last time slot, the ratio between regular calls and 373 SPIT calls initiated by the sender during the last time slot, etc. 374 The above mentioned statistics can also be bundled together and 375 passed only after the expiration of a timeout in order to increase 376 scalability. 378 Besides the estimation and the statistics itself, also the source 379 of the estimation may be transmitted. This way, an entity can 380 indicate, whether it has been involved in producing the estimate, 381 or just forwarded the received estimation along the path of the 382 INVITE. 384 Interface (a) 386 This interface is instantiated between the caller UA and the first 387 PS along the INVITE path. The relevance of interface (a) seems to 388 be rather limited. It does not seem a good idea to have the 389 caller UA neither estimating itself the likelihood of the INVITE 390 to belong to a SPIT call not transmitting statistics about the its 391 recent behavior. Moreover the instantiation of such an interface 392 could be maliciously used by entities initiating SPIT without the 393 PS having the proper means to judge if the information passed is 394 trustable or not. 396 Interface (b) 398 This interface is instantiated if there are two or more PS on the 399 path. In this case interface (b) is used between each consecutive 400 pair of them. It is used to send downstream information about the 401 infomration associated with an INVITE (e.g. the caller has a bad 402 reputation according ot the originating domain) and about most 403 relevant statistics of the INVITE initiator recent behavior. If 404 also the source of the estimation and statistics is transmitted, a 405 receiving PS may be able to judge how much trust to associate with 406 the indications based on local policies. Still depending on local 407 policies and legal rights the PS can decide to carry out 408 additional tests on the INVITE, initiate communication to other 409 entities (see Section 3.2 or Section 3.3 ), or block the call. 411 Interface (c) 413 This interface is instantiated between the last PS and the callee 414 UA. It is used to send downstream information about the 415 information associated with an INVITE (e.g. the caller did not 416 pass a CAPTCHA ) and about most relevant statistics of the INVITE 417 initiator recent behavior. If also the source of the estimation 418 and statistics is transmitted, the callee UA can judge how much 419 trust to associate to the indications based on local policies. 420 Still depending on local policies and legal rights the callee UA 421 can decide to carry out additional tests on the INVITE, initiate 422 communication to other entities (see Section 3.3), or block the 423 call without having the phone ringing. 425 3.1.2. Upstream 427 As for downstream communication above, we first describe 428 considerations that are common for all three interfaces before them 429 before pointing out differences between them. 431 All Interfaces (a), (b), and (c) 433 Upstream information is sent by entities after receiving an INVITE 434 as feedback to the entity from which they received it. It may 435 contain a feedback on the INVITE received. This feedback may be 436 sent before the call is established (if at all), after it was 437 blocked, while the call is established, and after the call has 438 been terminated. This information can help the sender in better 439 judging following calls that are forwarded and the users sending 440 the call initiation request or to block subsequent calls of the 441 same caller for the callee (feedback to insert users in black 442 lists hosted at the PS). An example for the delivery of feedback 443 information is reported in separate documents . 445 In addition to the feedback associated to a particular INVITE, 446 such interfaces, similar to downstream communication of 447 statistics, would allow to feed back statistics about the recent 448 behavior of the sender. An example of these statistics would 449 consist in the rate of SPIT calls (estimated using the feedback 450 mechanism) initiated by the sender during the last time slot, the 451 ratio between regular calls and SPIT calls initiated by the sender 452 during the last time slot, etc. The above mentioned statistics 453 can also be bundled together and passed only after the expiration 454 of a timeout in order to increase scalability. 456 Similar to downstream communication of information and statistics, 457 the source of the feedback information may be contained. This is 458 particularly interesting if the feedback was generated by the 459 callee who received the call. 461 Interface (a) 463 This interface is instantiated between the first PS along the 464 INVITE path and the caller UA. The relevance of interface (a) 465 seems to be rather limited. It does not seem to be a good idea to 466 give feedback to an initiator of SPIT on if and why requested 467 calls have been blocked. This would allow the SPIT initiator to 468 use this feedback for improving methods that bypass SPIT 469 prevention systems in the network. 471 A potential argument for sending a notification about detected 472 SPIT to the SPIT generator would be that many legal operators of 473 SPIT generating hosts might not be aware of this. Today, this is 474 the case for email spam. Most of them are generated by bot nets 475 where the legal operators of the contained hosts are not aware of 476 their hosts being used for this purpose. However, in case of SPIT 477 generation, it must be assumed that the generating software is 478 either a software not in control of the legal operator or it is 479 controlling the caller UA and capable of suppressing any feedback 480 that should not be seen by the legal operator. Therefore, this 481 means would probably not show the desired results. 483 Interface (b) 485 This interface is instantiated if there are two or more PS on the 486 path. In this case interface (b) is used between each consecutive 487 pair of them. It is used to feed back information about a certain 488 INVITE (e.g. callee indicated the call as SPIT) and about most 489 relevant statistics of the INVITE initiator recent behavior. If 490 also the source of the information and statistics is transmitted, 491 the PS can judge how much trust to associate to the indications 492 based on local policies and act consequently. Still depending on 493 local policies and legal rights the PS can decide to carry out 494 additional tests on selected subsequent INVITEs, initiate 495 communication to other entities (see Section 3.2 or Section 3.3), 496 or block selected subsequent calls. 498 Interface (c) 500 This interface is instantiated between the callee UA and the last 501 PS along the INVITE path. It is used to feed back information 502 about an INVITE (e.g. it belonged to a SPIT call) and about most 503 relevant statistics of the INVITE initiator recent behavior (even 504 if in this case the statistics can be rather limited since are 505 generated by the callee UA directly which has a narrow view on all 506 the traffic). This feedback is supposed to be a very important 507 one since it is the one directly generated by the callee UA (be it 508 the software or the human itself). The PS will therefore 509 associate high trust to such a feedback and act consequently. 510 Still depending on local policies and legal rights the PS can 511 decide to carry out additional tests on selected subsequent 512 INVITEs, initiate communication to other entities (see Section 3.2 513 or Section 3.3 ), or block selected subsequent calls. 515 3.2. Off-Path Interfaces between Proxy Servers 517 The basic idea of interface (d) is similar to the interface (b) where 518 different PS exchange SPIT-related information. The difference to 519 (b) is that for (d) this exchange is not bound to the path of an 520 INVITE message. At interface (d) information will be shared among PS 521 that collaborate on SPIT prevention (e.g. federations). While the 522 (b) interface can potentially be an inter-domain interface, (d) is 523 rather seen as an intra-domain interface where collaborating proxies 524 of a domain enforce a domain-wide SPIT prevention policy. For such a 525 purpose, information needs to be exchanged rather on collected 526 information than on single events of an observed INVITE message, 527 although this case should not be excluded. 529 Interface (d) has two major purposes. the first is the exchange of 530 information regarding certain caller UAs or certain administrative 531 domains estimated to produce SPIT. This does not necessarily require 532 exchanging observations per INVITE message, but rather on a regular 533 basis or incident-driven, for example whenever a PS detects a 534 correlation between several calls that have been classified as SPIT. 536 The exchange of such information may, for example, lead to a 537 classification of a source address or a source network as source of 538 SPIT which requires and update of blacklists and SPIT detection 539 mechanisms. 541 Consequently, the second major purpose of interface (d) is exchanging 542 information that updates or synchronizes the prevention mechanisms 543 that are acting at different PS. This includes particularly 544 blacklist and whitelist entries, but also other SPIT prevention 545 mechanisms may make use of exchanged information. 547 Still, interface (d) may also serve for exchanging estimated results 548 associated to single calls, for example for collecting this 549 information at a central repository that serves for updating domain- 550 wide SPIT prevention policies. 552 3.3. Interfaces to Special SPIT Prevention Entities 554 Communication to special SPIT prevention entities can be performed 555 either by a proxy server via interface (e) or by the callee UA via 556 interface (f). We first discuss considerations that apply to both 557 interfaces before pointing out differences between the two. 559 Both Interfaces (e) and (f) 561 The service offered by special SPIT prevention entities is related 562 to the estimation of an INVITE to belong to a SPIT call. This 563 communication is supposed to be instantiated in order to off-load 564 computational intensive tasks to an external entity. 566 The communication with this SPIT prevention entity follows the 567 client-server scheme. The PS or UA acting as client requests an 568 estimation for a given INVITE message to belong to a SPIT call. 569 The estimation is performed by the SPIT prevention entity acting 570 as server. A request may include call parameters to be used by 571 the server when performing the estimations. 573 Interface (e) 575 This interface is instantiated between a proxy server and a 576 special SPIT prevention entity in order to request for SPIT 577 estimations. In addition to the above considerations it is 578 necessary to note that such service could be less personalized 579 with respect to the service offered over the interface (f) since 580 the estimations have to be general in order to deal with all the 581 users served by the proxy server using such an interface. 582 Otherwise the instantiated functions seems to be identical. 584 Interface (f) 586 This interface is instantiated between a UA and a special SPIT 587 prevention entity in order to request for SPIT estimations. In 588 addition to the above considerations it is necessary to note that 589 such service should be more personalized with respect to the 590 service offered over the interface (e) since the estimations have 591 to be specific to the callee requesting them over the interface. 592 Otherwise the instantiated functions seems to be identical. 594 4. Need for Standardization 596 The considerations above indicate that there is an actual need for 597 standardization of communication information. 599 The strongest need seems to be for interfaces (b) and (c) in upstream 600 direction for providing feedback on calls or call attempts. But also 601 in downstream direction, there seems to be an obvious need to support 602 this communication by providing a standard for it. This concerns 603 both in intra- and inter-domain communication. 605 The situation is very different for Interface (a). The 606 considerations in Section 3.1 indicate that it might even be a bad 607 idea to provide any feedback via (a) at all. Therefore, we do not 608 see a need to work on standards for interface (a). 610 Interface (d) seems to be useful but with a more limited scope of 611 application within a (federated) administrative domain (intra- 612 domain). Still for interoperability between different devices it 613 appears to be beneficial to have a standard way of sharing SPIT- 614 related information. 616 For the remaining interfaces (e) and (f) we do not yet see a clear 617 need for interoperability. SPIT prevention engines to which 618 functions are outsourced by a PS or callee UA may typically be part 619 of a solution that is offered together with the PS or with a set of 620 SIP UAs. For these cases proprietary communication protocols appear 621 to be sufficient. Still need for standardization may arise at later 622 stages when SPIT prevention entities become more common. 624 4.1. Preliminary Protocol Considerations 626 The fact that the communication over interfaces (b) and (c) follows 627 the same path as the SIP signaling itself may influence the choice of 628 the signaling protocols used for exchanging information at the 629 interfaces. An obvious choice to be discussed would be embedding the 630 SPIT information directly in the SIP messages flowing among the 631 entities anyway. 633 For the other interfaces (d), (e) and (f) other signaling protocols 634 may be preferable since the communication will happen anyway not 635 synchronously with the SIP messages used to initiate the session. An 636 example could be the exchange of XML files among different entities. 638 5. Conclusions 640 This memo addresses the necessity of providing standards for 641 communication between entities involved in SPIT prevention. For this 642 purpose a reference scenario is defined with involved entities and 643 interfaces between them. For each interface the need for it and the 644 need for standards for is discussed. 646 This memo is intended to stimulate a discussion on SPIT prevention 647 and to reach consensus on the identification of standardization goals 648 and reference architectures in this area. Some of the considerations 649 in Section 3 seem to indicate that there is an actual need to 650 standardize communication for some of the discussed interfaces. This 651 memo does ot try to standardize any solution to the problems 652 identified. The necessary work outcoming from the discussion 653 stimulated will have to be carried out in separate documents. 655 6. Security Considerations 657 This memo discusses the exchange of information related to SPIT 658 prevention. This includes information on particular calls or call 659 attempts as well as information on call initiators potentially being 660 a source of SPIT. 662 Exchanging per-call information may violate the privacy of a caller. 663 Therefore, instantiations of the discussed exchange of information 664 need to be carefully checked for compliance with legal regulations of 665 information privacy. Also, since this information may be sensitive, 666 appropriate steps should be undertaken to provide confidentiality 667 when it is transmitted over the Internet. 669 Both, per-call information and information of a caller being a source 670 of SPIT may be a target of denial-of-service attacks. If such 671 messages are faked, a regular caller may be blocked network-wide and 672 not able anymore to perform calls. Therefore, integrity and 673 authenticity need to be provided when this kind of information is 674 transmitted over the Internet. 676 7. IANA Considerations 678 This document has no actions for IANA. 680 8. Informative References 682 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 683 Protocol (SIP) and Spam", RFC 5039, January 2008. 685 [I-D.tschofenig-sipping-framework-spit-reduction] 686 Tschofenig, H., Schulzrinne, H., Wing, D., Rosenberg, J., 687 and D. Schwartz, "A Framework to tackle Spam and Unwanted 688 Communication for Internet Telephony", 689 draft-tschofenig-sipping-framework-spit-reduction-02 (work 690 in progress), November 2007. 692 [I-D.tschofenig-sipping-spit-policy] 693 Tschofenig, H., Wing, D., Schulzrinne, H., Froment, T., 694 and G. Dawirs, "A Document Format for Expressing 695 Authorization Policies to tackle Spam and Unwanted 696 Communication for Internet Telephony", 697 draft-tschofenig-sipping-spit-policy-02 (work in 698 progress), November 2007. 700 Authors' Addresses 702 Saverio Niccolini 703 NEC Laboratories Europe, NEC Europe Ltd. 704 Kurfuersten-Anlage 36 705 Heidelberg 69115 706 Germany 708 Phone: +49 (0) 6221 4342 118 709 Email: niccolini@nw.neclab.eu 710 URI: http://www.nw.neclab.eu 711 Juergen Quittek 712 NEC Laboratories Europe, NEC Europe Ltd. 713 Kurfuersten-Anlage 36 714 Heidelberg 69115 715 Germany 717 Phone: +49 (0) 6221 4342 115 718 Email: niccolini@nw.neclab.eu 719 URI: http://www.nw.neclab.eu 721 Jan Seedorf 722 NEC Laboratories Europe, NEC Europe Ltd. 723 Kurfuersten-Anlage 36 724 Heidelberg 69115 725 Germany 727 Phone: +49 (0) 6221 4342 221 728 Email: seedorf@nw.neclab.eu 729 URI: http://www.nw.neclab.eu 731 Full Copyright Statement 733 Copyright (C) The IETF Trust (2008). 735 This document is subject to the rights, licenses and restrictions 736 contained in BCP 78, and except as set forth therein, the authors 737 retain all their rights. 739 This document and the information contained herein are provided on an 740 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 741 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 742 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 743 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 744 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 745 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 747 Intellectual Property 749 The IETF takes no position regarding the validity or scope of any 750 Intellectual Property Rights or other rights that might be claimed to 751 pertain to the implementation or use of the technology described in 752 this document or the extent to which any license under such rights 753 might or might not be available; nor does it represent that it has 754 made any independent effort to identify any such rights. Information 755 on the procedures with respect to rights in RFC documents can be 756 found in BCP 78 and BCP 79. 758 Copies of IPR disclosures made to the IETF Secretariat and any 759 assurances of licenses to be made available, or the result of an 760 attempt made to obtain a general license or permission for the use of 761 such proprietary rights by implementers or users of this 762 specification can be obtained from the IETF on-line IPR repository at 763 http://www.ietf.org/ipr. 765 The IETF invites any interested party to bring to its attention any 766 copyrights, patents or patent applications, or other proprietary 767 rights that may cover technology that may be required to implement 768 this standard. Please address the information to the IETF at 769 ietf-ipr@ietf.org. 771 Acknowledgment 773 Funding for the RFC Editor function is provided by the IETF 774 Administrative Support Activity (IASA).