idnits 2.17.1 draft-niccolini-sipping-spam-feedback-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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 475. 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 98: '...he spam feedback SHOULD carry informat...' RFC 2119 keyword, line 99: '...formation that are redundant SHOULD be...' 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 14, 2008) is 5916 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 NEC 4 Intended status: Standards Track K. Fischer 5 Expires: August 17, 2008 Siemens Enterprise Communications 6 D. Wing 7 Cisco System, Inc. 8 M. Stiemerling 9 NEC 10 H. Tschofenig 11 Nokia Siemens Networks 12 February 14, 2008 14 Spam feedback for SIP 15 draft-niccolini-sipping-spam-feedback-00 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 August 17, 2008. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2008). 46 Abstract 48 This document gives on overview of possible mechanisms for SIP UAs to 49 feedback spam information to the system (e.g. other SIP entities like 50 upstream SIP proxies) thus they can use this information for handling 51 subsequent calls (e.g. blacklist the caller, input this info to 52 reputation systems, compute spam-specific caller statistics, etc.). 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. SIP Spam Feedback: sending operations . . . . . . . . . . . . 3 58 2.1. Alternatives for sending spam feedbacks . . . . . . . . . 4 59 2.1.1. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1.2. Event package usage . . . . . . . . . . . . . . . . . 4 61 2.1.2.1. Overview . . . . . . . . . . . . . . . . . . . . . 4 62 2.1.2.2. Subscribe behavior . . . . . . . . . . . . . . . . 5 63 2.1.2.3. Notify behavior . . . . . . . . . . . . . . . . . 6 64 3. SIP Spam Feedback: system operations . . . . . . . . . . . . . 6 65 4. Advantages and disadvantages of alternatives . . . . . . . . . 7 66 5. Additional considerations of feedback operations . . . . . . . 8 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 73 Intellectual Property and Copyright Statements . . . . . . . . . . 12 75 1. Introduction 77 For the purpose of SPIT prevention it would be nice to have a 78 mechanism for users to report the fact that they received a spam 79 call. For example, a button on the user interface of the client 80 (either hardware or software) might empower callees to inform the 81 system that a particular caller initiated a spam call to the callee 82 (see also [RFC5039]). This information can be used in many ways 83 depending on the configuration of the system and on user preferences 84 (e.g. can be used to add the caller to the callee's personal black 85 list, to inform a reputation system, to apply particular call 86 handling to subsequent calls of such caller either making him solving 87 a CAPTCHA before initiating new calls or making him solving a 88 computational puzzle, etc.). The discussion on how to use the user 89 feedback depending on the configuration of the system and on user 90 preferences is out of the scope of this document. The scope of this 91 document is to highlight possible alternatives how this feedback 92 should be delivered to the system in order to make a decision how 93 this feedback should be implemented. 95 2. SIP Spam Feedback: sending operations 97 A UA generates a spam feedback after the user press the "spam" 98 button. The spam feedback SHOULD carry information about the call 99 and its originator. Information that are redundant SHOULD be 100 avoided. Such information are taken into account by the system in 101 order to apply different policies depending on system configuration 102 or on user preferences. Examples of information about the call are, 103 but not limited to, listed here: 104 o caller SIP URI; 105 o callee SIP URI; 106 o Call-ID; 107 o call start time (exact definition of call start time has to be 108 included); 109 o call end time (exact definition of call start time has to be 110 included); 111 o caller signaling contact address (IP address and port); 112 o callee signaling contact address (IP address and port); 113 o caller media address (IP address and port); 114 o callee media address (IP address and port); 115 o Path Information (Via, Route, Record-Route, Path headers); 116 o Alert-Info (if present in the request); 117 o etc. (to be defined). 119 2.1. Alternatives for sending spam feedbacks 121 The authors envision two alternatives to implement the spam feedback: 122 o using an additional header is inserted the BYE message, which is 123 already generated by the UA; 124 o using an event package for spam feedbacks (to be defined), the 125 system (e.g. a SIP proxy) SUSCRIBE to UA spam feedback service, 126 the UA NOTIFY the system each time the "spam" button is pressed by 127 the user. 128 Both methods have pros and cons. Discussion about which is the best 129 alternative for the purpose of sending spam feedbacks should take 130 place in the SIPPING WG. 132 2.1.1. ABNF 134 ABNF using the ABNF syntax of [RFC3261]. Such ABNF can be used to 135 define the additional header of the BYE message or the body of the 136 NOTIFY message. 138 Spam = "Spam" HCOLON spam-value 139 ; examples: 140 ; Spam: 1; To: Bob ; 141 ; From: Alice ; 142 ; tag=1928301774; 143 ; Call-ID: a84b4c76e66710@pc33.atlanta.com 144 ; ... 145 spam-value = 1 *(SEMI spam-params) 146 spam-params = To / From / Call-ID / 147 Call-start-val / Call-end-val / 148 Caller-sign-val / Callee-sign-val / 149 Caller-media-val / Callee-media-val / 150 Via / Route / Record-Route / 151 Alert-Info / ... 152 Call-start-val = "Call-start" EQUAL date 153 Call-end-val = "Call-end" EQUAL date 154 Caller-sign-val = "Caller-sign" EQUAL hostport 155 Callee-sign-val = "Callee-sign" EQUAL hostport 156 Caller-media-val = "Caller-media" EQUAL hostport 157 Callee-media-val = "Callee-media" EQUAL hostport 159 Figure 1: ABNF 161 2.1.2. Event package usage 163 2.1.2.1. Overview 165 [RFC3265] specifies an extension to SIP providing an extensible 166 framework by which SIP nodes can request notification from remote 167 nodes indicating that certain events have been occurred. This 168 framework can be applied to realize an notification mechanism of spam 169 feedback from a SIP UA towards a server like a SIP proxy. A server 170 interested in feedback if a call is considered as spit / spam by the 171 user, subscribes to the new defined event package 'spam-feedback' at 172 the SIP UA. After the user has pressed the "spam" button, the SIP UA 173 notifies the server about the spam call. The NOTIFY message includes 174 also some information to correlate the feedback with a specific call 175 and to provide additional information. Figure 2 depicts the general 176 call flow, which is explained in the following sections. Call 177 signaling specific messages like INVITE, 18x or 200 responses are 178 omitted from the figure for simplicity. 180 SIP proxy / 181 SIP UA SPAM server 182 | | 183 | SUBSCRIBE ('spam-feedback') | 184 |<-------------------------------| 185 | | 186 | 200 | 187 |------------------------------->| 188 | | 189 | NOTIFY ('spam-feedback') | 190 |------------------------------->| 191 | | 192 | 200 | 193 |<-------------------------------| 194 spam button | | 195 pressed | | 196 ------->| | 197 | NOTIFY ('spam-feedback') | 198 |------------------------------->| 199 | | 200 | 200 | 201 |<-------------------------------| 202 | | 204 Figure 2: Overview call flow spam feedback event mechanism 206 2.1.2.2. Subscribe behavior 208 A SPAM / SIP server interested in spam feedback from a SIP UA sends a 209 SUBSCRIBE request to the dedicated SIP UA. The request contains a 210 Event header indicating that the 'spam-feedback' event package shall 211 be subscribed. The request may contain also an Expires header 212 indicating the duration of the subscription. If no Expires header is 213 present, the subscription has an unlimited duration. At any time 214 before a subscription expires, the subscriber may refresh the timer 215 on such a subscription by sending another SUBSCRIBE request on the 216 same dialog as the existing subscription. 218 On receipt of a SUBSCRIBE request the SIP UA should check that the 219 event package specified in the Event header is understood. If not, a 220 "489 Bad Event" response should be returned. The SIP UA should check 221 if the requesting server is authorized to subscribe to the event 222 package. Prior to authorization the SIP UA needs to authenticate the 223 server. One way achieving this is to use a TLS connection to the 224 spam / SIP server, which might be already established to protect SIP 225 registration and call signaling. Usually, the server is 226 authenticated during TLS handshake, e.g. by a X.509 certificate, 227 whereas the SIP UA is authenticated by SIP digest ([RFC3261] and 228 [RFC2617]) on top of TLS. TLS provides also additional security 229 properties, which addresses the security considerations of [RFC3265] 230 (please refer to Section 6). 232 Based on the configured policy the SIP UA accepts the SUBSCRIBE 233 request by sending a 200 response, temporarily accepts the request 234 with a 202 response or declines it by sending a non 200 class 235 response like "403 Forbidden" or "603 Declined". 237 2.1.2.3. Notify behavior 239 After the SIP UA has accepted the subscription, a NOTIFY message is 240 sent directly after the 200 response to indicate the initial state. 241 The NOTIFIY Event header contains the 'spam-feedback' package name. 242 The body should be empty, because no spam feedback needs to be 243 notified initially. The NOTIFY message is sent over the already 244 established TLS connection. 246 When a user receives a call considered as spam, he presses the "spam" 247 button, which initiates a new NOTIFY message from the UA to the 248 server. In contrast to the initial NOTIFY message, the body contains 249 information about the call and its originator. Such information are 250 taken into account by the spam system in order to apply different 251 policies depending on system configuration or on user preferences. 252 Refer to Section 2 for a list of carried information. 254 [[Note: The concrete specification of the 'spam-feedback' event 255 package will be added in a future version.]] 257 3. SIP Spam Feedback: system operations 259 The system (e.g. a SIP proxy) that receives a notification of a 260 certain call being spam should apply the policies defined in the 261 system configuration and in the user preferences in order to handle 262 subsequent calls coming from that caller. Examples of behavior 263 include: 264 o insert the caller in the callee's personal blacklist; 265 o input the feedback to a reputation system computing the reputation 266 of the callers; 267 o configure the system to apply particular actions on subsequent 268 calls initiated by such a caller (e.g. route to voicemail, 269 challenge with a CAPTCHA, challenge with a computational puzzle, 270 etc.) 272 4. Advantages and disadvantages of alternatives 274 We provide here a list of advantages and disadvantages in order to 275 stimulate discussion on which technique should be used to send 276 feedback. 278 Advantages for using BYE are: 279 o the mechanism can piggyback on a message that is already present 280 and that the UA is sending anyway; 281 o it gives users a positive feeling/knowledge (if realized using a 282 special button) that there is a special entity in the network that 283 takes care of spam information (other than the proxy only) and 284 (theoretically) will do something useful with it. 286 Disadvantages for using BYE are: 287 o the mechanisms has to be piggybacked on the BYE; this means the 288 user has to decide if the call is spam at the same time the user 289 terminates the call. This could be difficult with some user 290 interfaces; 291 o the feedback information can in principle be routed upstream to a 292 SIP proxy that can make use of it (if the sender proxy is the one 293 controlled by the spammer this would mean giving him information 294 on how the call was evaluated). Thus it is necessary to strip 295 feedback information when the BYE leaves the caller's 296 administrative domain (this puts additional load on the proxy). 297 Failure to strip that information will allow the caller to realize 298 if their call was marked as spam by the called party (privacy and 299 security risk). 301 Advantages for using NOTIFY are: 302 o feedback information is sent only to SIP proxy or other special 303 devices that are the intended recipients of such a message and 304 that can make use of it; 305 o it can be delivered after the BYE (e.g. using a special dialing 306 sequence; 308 o there is no need to require header stripping at the network 309 administrative boundary; 310 o it is easier (with respect ot the usage of BYE) to authorize the 311 mechanisms; 312 o it gives users a positive feeling/knowledge that there is a 313 special entity in the network that takes care of spam information 314 (other than the proxy only) and (theoretically) will do something 315 useful with it 317 Disadvantages for using NOTIFY are: 318 o it requires an additional message; 319 o it requires additional infrastructural devices to be deployed 320 (even if their introduction would not be too difficult since they 321 are orthogonal to the signalling path). 323 From a first analysis the usage of NOTIFY seems to be preferred but 324 it is up to discussion in the community to reach consensus on this 325 topic. 327 5. Additional considerations of feedback operations 329 This document does not address important considerations on how and if 330 the system (e.g. the SIP proxy serving the UA that received the spam 331 call) should pass the information of a certain call being spam to 332 other upstream proxies (e.g. to the SIP proxy in the originating 333 domain). Such considerations are out of the scope of this document. 334 The authors envision that such discussion should take place in 335 another draft and investigate if additional headers or error messages 336 should be defined to report upstream proxies about a call being 337 considered spam by a certain domain or not. Also passing spam 338 scoring information to upstream proxies is a possibility that should 339 be considered in such draft and the appropriate security 340 considerations shold be applied. 342 6. Security Considerations 344 Some session requests may be spam for some users but not for others, 345 it should be clear that the feedback is not providing a general 346 security assessment of the call being spam or of the caller being 347 abusive, but a personal one. The system should process spam 348 feedbacks preserving normal operations for all users without letting 349 some "mafia" users exploiting this mechanism to create DoS attacks 350 denying users to call. The feedback message should be therefore 351 challenged and authentication mechanisms should be applied. Also if 352 the spam feedback is used to blacklist caller or entire domains, it 353 should be used very carefully. 355 The security considerations described in [RFC3265] are inherited and 356 need also be considered by applying the general notification 357 framework for spam feedback. Most of the security threats are 358 directly addressed by an authenticated TLS connection between the 359 notifier and the subscriber. 361 [[Note: Additional text regarding each threat of RFC 3265 is added in 362 a later version ]] 364 7. IANA Considerations 366 [[This section will be completed in a later version of this 367 document.]] 369 8. References 371 8.1. Normative References 373 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 374 A., Peterson, J., Sparks, R., Handley, M., and E. 375 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 376 June 2002. 378 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 379 Event Notification", RFC 3265, June 2002. 381 8.2. Informative References 383 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 384 Leach, P., Luotonen, A., and L. Stewart, "HTTP 385 Authentication: Basic and Digest Access Authentication", 386 RFC 2617, June 1999. 388 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 389 Protocol (SIP) and Spam", RFC 5039, January 2008. 391 Authors' Addresses 393 Saverio Niccolini 394 NEC Laboratories Europe, NEC Europe Ltd. 395 Kurfuersten-Anlage 36 396 Heidelberg 69115 397 Germany 399 Phone: +49 (0) 6221 4342 118 400 Email: saverio.niccolini@nw.neclab.eu 401 URI: http://www.nw.neclab.eu 403 Kai Fischer 404 Siemens Enterprise Communications GmbH & Co. KG 405 Schertlinstr. 8 406 Munich 81379 407 Germany 409 Phone: +49 (0) 89 722-37360 410 Email: kai.fischer@siemens.com 412 Dan Wing 413 Cisco System, Inc. 414 170 West Tasman Drive 415 San Jose, CA 95134 416 US 418 Email: dwing@cisco.com 420 Martin Stiemerling 421 NEC Laboratories Europe, NEC Europe Ltd. 422 Kurfuersten-Anlage 36 423 Heidelberg 69115 424 Germany 426 Phone: +49 (0) 6221 4342 113 427 Email: stiemerling@nw.neclab.eu 428 URI: http://www.nw.neclab.eu 429 Hannes Tschofenig 430 Nokia Siemens Networks 431 Otto-Hahn-Ring 6 432 Munich, Bavaria 81739 433 Germany 435 Email: Hannes.Tschofenig@nsn.com 437 Full Copyright Statement 439 Copyright (C) The IETF Trust (2008). 441 This document is subject to the rights, licenses and restrictions 442 contained in BCP 78, and except as set forth therein, the authors 443 retain all their rights. 445 This document and the information contained herein are provided on an 446 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 447 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 448 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 449 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 450 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 451 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 453 Intellectual Property 455 The IETF takes no position regarding the validity or scope of any 456 Intellectual Property Rights or other rights that might be claimed to 457 pertain to the implementation or use of the technology described in 458 this document or the extent to which any license under such rights 459 might or might not be available; nor does it represent that it has 460 made any independent effort to identify any such rights. Information 461 on the procedures with respect to rights in RFC documents can be 462 found in BCP 78 and BCP 79. 464 Copies of IPR disclosures made to the IETF Secretariat and any 465 assurances of licenses to be made available, or the result of an 466 attempt made to obtain a general license or permission for the use of 467 such proprietary rights by implementers or users of this 468 specification can be obtained from the IETF on-line IPR repository at 469 http://www.ietf.org/ipr. 471 The IETF invites any interested party to bring to its attention any 472 copyrights, patents or patent applications, or other proprietary 473 rights that may cover technology that may be required to implement 474 this standard. Please address the information to the IETF at 475 ietf-ipr@ietf.org. 477 Acknowledgment 479 Funding for the RFC Editor function is provided by the IETF 480 Administrative Support Activity (IASA).