idnits 2.17.1 draft-froment-sipping-spit-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 397. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 408. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 421. 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 (July 14, 2008) is 5755 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5039' is mentioned on line 332, but not defined == Missing Reference: 'RFC4474' is mentioned on line 320, but not defined ** Obsolete undefined reference: RFC 4474 (Obsoleted by RFC 8224) == Missing Reference: 'I-D.jennings-sip-hashcash' is mentioned on line 311, but not defined == Missing Reference: 'I-D.ietf-sip-consent-framework' is mentioned on line 305, but not defined == Missing Reference: 'RFC3880' is mentioned on line 316, but not defined == Missing Reference: 'RFC5228' is mentioned on line 335, but not defined == Missing Reference: 'RFC4745' is mentioned on line 324, but not defined == Missing Reference: 'RFC5025' is mentioned on line 329, but not defined Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING H. Tschofenig, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Informational G. Dawirs 5 Expires: January 15, 2009 University of Namur 6 T. Froment 7 Alcatel-Lucent 8 D. Wing 9 Cisco 10 H. Schulzrinne 11 Columbia University 12 July 14, 2008 14 Requirements for Authorization Policies to tackle Spam and Unwanted 15 Communication for Internet Telephony 16 draft-froment-sipping-spit-requirements-03 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 15, 2009. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2008). 47 Abstract 49 Spam over Internet Telephony (SPIT) is one of the foreseen future 50 forms of spamming that SIP open-wide networks may have to handle. 51 SPIT also has more impact on users than email spam since it is more 52 intrusive. Email as a store-and-forward communication mechanism 53 allows for several filtering mechanisms to be applied to the full 54 content before being presented to the user. Session Initiation 55 Protocol (SIP) interaction is, in contrast, real-time communication 56 and therefore does not provide much information prior to the 57 transmission of the content, making it both harder to filter and more 58 annoying to users. The responsibility for filtering, blocking calls, 59 or taking any other preventive action can belong to different 60 elements in the call flow and may depend on various factors. This 61 document discusses the requirements to define authorization policies 62 that should allow end users or other parties to setup anti-SPIT 63 policies for triggering these actions. These policies typically 64 match a particular SIP communication pattern based on a number of 65 attributes. The range of attributes includes information provided, 66 for example, by the SIP protocol itself, by the SIP identity 67 mechanism, by information carried within SAML assertions or by 68 reputation systems of social networks. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.3. Transformations . . . . . . . . . . . . . . . . . . . . . 8 78 3.4. Generic Requirements . . . . . . . . . . . . . . . . . . . 8 79 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 82 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 84 7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 Intellectual Property and Copyright Statements . . . . . . . . . . 15 88 1. Introduction 90 Today, most of the anti-SPAM solutions are coming from email 91 experience, and their applicability to SIP has been discussed 92 in[RFC5039]. 94 As outlined in [RFC5039], it is likely that many different techniques 95 will need to be combined to deal with SPIT. Users will make 96 different trade-offs when rejecting suspicious calls, for example, 97 trading a lower probability of being interrupted for occasional 98 erroneous call rejection. Also, different types of users, such as 99 businesses and private residences, have different call 100 characteristics. We propose to define a policy language that allows 101 users to easily define their call handling preferences for SPIT. The 102 policy would be executed by trusted SIP proxy or any other SIP 103 element, altering how they handle incoming requests. Policy rules 104 are likely to be define by different actors, including end users 105 themselves, parents on behalf of their children or system 106 administrators. This document enumerates and motivates requirements 107 for such a policy language. Some attributes in an incoming message 108 play a more important role than others. For example, applying 109 authorization policies based on authenticated identity [RFC4474], is 110 an effective way to make decisions regarding unwanted traffic in some 111 cases. 113 This document identifies requirements for authorization policies when 114 used to influence message handling for unwanted communication 115 attempts. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119], 122 with the important qualification that, unless otherwise stated, these 123 terms apply to the design of the authorization policies, not its 124 implementation or application. 126 3. Requirements 128 This section lists the requirements categorized according to their 129 applicability for the "conditions", "actions" and "transformation" 130 parts typically found in authorization policies. 132 3.1. Conditions 134 The first set of requirements refer to identity related information. 136 Req-C 1: Policies MUST allow conditions to express single 137 authenticated identities. 139 Req-C 2: Policies MUST allow filtering based on the domain part of 140 the identity. 142 Req-C 3: Policies MUST support the differentiation between 143 authenticated and unauthenticated identities. 145 Req-C 4: Policies MUST be able to express exceptions within a group 146 of users or a domain. 148 Req-C 5: Policies SHOULD allow an anonymous identity as a condition. 150 Message handling may depend on the content of SIP request header 151 fields. 153 Req-C 6: Policies SHOULD allow conditions to refer to the 154 "destination" (which corresponds to the "Request-URI") and 155 "original-destination" (which corresponds to the "To" header). 157 Req-C 7: Policies SHOULD allow conditions to refer to the method 158 invoked by the caller (e.g., INVITE, REFER, MESSAGE, 159 SUBSCRIBE). 161 Motivation: Some SIP methods are more intrusive than others 162 (the default applicative behaviour when SIP MESSAGEs are 163 received is often to pop-up the message on the UAS side), 164 adopting a different filtering policy depending of the method 165 invoked will enhance the user's protection. 167 Req-C 8: Policies SHOULD allow the entity that writes the rules to 168 take actions on messages that are marked as Spam. 170 Note that such a condition element should be seen in 171 context of the authenticated domain or, otherwise, of a 172 protected information to avoid security 173 vulnerabilities. 175 Req-C 9: Policies MAY allow to make decisions based on the current 176 state of the user. E.g., his sphere or other presence 177 information. 179 Req-C 10: Policies SHOULD support consitions based on the content 180 type and/or offered (or used) media of a message. 182 Message handling may depend on time of day or the date. 184 Req-C 11: Policies SHOULD allow conditions that refer to the 185 reception date, time, timezone or period of time of the 186 incoming request. 188 Message handling might be based on the caller's preferred languages. 190 Req-C 12: Policies SHOULD allow to make decisions based on the 191 languages in which the originator of the call wishes to 192 communicate. 194 3.2. Actions 196 Req-A 1: Policies SHOULD allow messages to get "blocked", i.e., to 197 stop forwarding the request and to return an answer with a 198 "403 Forbidden''. 200 Req-A 2: Policies SHOULD allow messages to get "politely blocked", 201 i.e., to stop the request with, for instance, a "486 Busy" 202 response. 204 Req-A 3: Policies SHOULD allow messages to get "marked", i.e., to 205 forward the request and mark it as "potential Spam" for 206 filtering at the end point or at subsequent entities along the 207 signaling path. 209 Req-A 4: Policies SHOULD allow messages to be "allowed", i.e., to 210 forward this message. 212 Req-A 5: Policies MUST allow messages to be "redirected" to, for 213 example, voicemail or to a different device in the possession 214 of the user. 216 Req-A 6: Policies MUST allow executing other SPIT prevention 217 procedures, such as computational puzzles 218 [I-D.jennings-sip-hashcash] or the consent framework 219 [I-D.ietf-sip-consent-framework]. A specification developing 220 a SPIT prevention mechanism should provide information on how 221 they can be incorporated into the authorization policy 222 framework. 224 Req-A 7: Policies MAY allow an e-mail (or SMS, MMS) or other 225 notifications to be sent to the user about the actions taken 226 due to a specific call attempt. 228 R8: Policies MAY allow the usage of one or many feedback 229 mechanisms. 231 3.3. Transformations 233 Req-T 1: Policies SHOULD allow SIP messages to be marked with a 234 certain SPIT probability in case SPIT detection and policy 235 enforcement is excecuted on different entities. For example, 236 a network element might run a statistical SPIT detection tool 237 but the authorization policies are executed on a different 238 entity, such as the end host. Note that it needs to be 239 ensured that an adversary is not able to set the SPIT 240 probabity values since otherwise the authorization policies 241 that rely on such information are misguided. 243 3.4. Generic Requirements 245 Req-G 1: It SHOULD be possible to allow a hierarchy of authorization 246 policies to be used. 248 It is quite likely that a rules from different rule writing 249 entities are provided. For example, in a company environment 250 policies from the system administrator are provided in 251 addition to the end users policies. The former might reflect 252 the overall company policy. The impact for the policy is 253 mainly on the definition of an appropriate conflict resolution 254 mechanism. 256 Req-G 2: It MUST be possible for a client to learn the supported 257 authorization policy capabilities implemented by the server. 259 Req-G 3: Policies MUST be extensible and these extensions MUST exist 260 within a different namespace. Furthermore, a published schema 261 and the namespace for elements defined within it MUST NOT be 262 altered by future specifications. 264 Req-G 4: The policies MUST provide a mandatory-to-implement conflict 265 resolution mechanism. 267 4. IANA Considerations 269 This document does not require actions by IANA. 271 5. Security Considerations 273 This document describes the requirements for elements contained in 274 the authorization policies that allow communication attempts to be 275 treated differently based on the content of the message, time-of-day, 276 context of the user, reputation of the sending party, and many other 277 factors. 279 The security concerns are related to the ability of certain entities 280 to create, update and delete authorization policies. If an 281 unauthorized entity is allowed to modify policies (and to distribute 282 them to other domains) then a denial of service attack is the 283 consequence with impact for more than a single end point. These 284 security aspects are, however, not the subject of this document. 286 6. Acknowledgements 288 The content of this document is inspired by the work of CPL 289 [RFC3880], SIEVE [RFC5228], Common Policy [RFC4745] and Presence 290 Authorization Policy [RFC5025]. We would like to thank the authors 291 of these documents for their work. 293 Furthermore, we would like to thank Eva Leppanen for the detailed 294 review provided in June 2006. 296 7. References 298 7.1. Normative References 300 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 301 Requirement Levels", BCP 14, RFC 2119, March 1997. 303 7.2. References 305 [I-D.ietf-sip-consent-framework] 306 Rosenberg, J., Camarillo, G., and D. Willis, "A Framework 307 for Consent-based Communications in the Session Initiation 308 Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work 309 in progress), January 2008. 311 [I-D.jennings-sip-hashcash] 312 Jennings, C., "Computational Puzzles for SPAM Reduction in 313 SIP", draft-jennings-sip-hashcash-06 (work in progress), 314 July 2007. 316 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 317 Language (CPL): A Language for User Control of Internet 318 Telephony Services", RFC 3880, October 2004. 320 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 321 Authenticated Identity Management in the Session 322 Initiation Protocol (SIP)", RFC 4474, August 2006. 324 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 325 Polk, J., and J. Rosenberg, "Common Policy: A Document 326 Format for Expressing Privacy Preferences", RFC 4745, 327 February 2007. 329 [RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, 330 December 2007. 332 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 333 Protocol (SIP) and Spam", RFC 5039, January 2008. 335 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 336 Language", RFC 5228, January 2008. 338 Authors' Addresses 340 Hannes Tschofenig (editor) 341 Nokia Siemens Networks 342 Otto-Hahn-Ring 6 343 Munich, Bavaria 81739 344 Germany 346 Email: Hannes.Tschofenig@nsn.com 347 URI: http://www.tschofenig.com 349 Geoffrey Dawirs 350 University of Namur 351 21, rue Grandgagnage 352 Namur B-5000 353 Belgique 355 Email: gdawirs@gdawirs.be 357 Thomas Froment 358 Alcatel-Lucent 359 Route de Villejust 360 Nozay, Paris 91620 361 France 363 Email: Thomas.Froment@alcatel-lucent.fr 365 Dan Wing 366 Cisco 367 170 West Tasman Drive 368 San Jose, CA 95134 369 USA 371 Email: dwing@cisco.com 372 Henning Schulzrinne 373 Columbia University 374 Department of Computer Science 375 450 Computer Science Building 376 New York, NY 10027 377 US 379 Phone: +1 212 939 7004 380 Email: hgs@cs.columbia.edu 381 URI: http://www.cs.columbia.edu 383 Full Copyright Statement 385 Copyright (C) The IETF Trust (2008). 387 This document is subject to the rights, licenses and restrictions 388 contained in BCP 78, and except as set forth therein, the authors 389 retain all their rights. 391 This document and the information contained herein are provided on an 392 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 393 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 394 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 395 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 396 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 397 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 399 Intellectual Property 401 The IETF takes no position regarding the validity or scope of any 402 Intellectual Property Rights or other rights that might be claimed to 403 pertain to the implementation or use of the technology described in 404 this document or the extent to which any license under such rights 405 might or might not be available; nor does it represent that it has 406 made any independent effort to identify any such rights. Information 407 on the procedures with respect to rights in RFC documents can be 408 found in BCP 78 and BCP 79. 410 Copies of IPR disclosures made to the IETF Secretariat and any 411 assurances of licenses to be made available, or the result of an 412 attempt made to obtain a general license or permission for the use of 413 such proprietary rights by implementers or users of this 414 specification can be obtained from the IETF on-line IPR repository at 415 http://www.ietf.org/ipr. 417 The IETF invites any interested party to bring to its attention any 418 copyrights, patents or patent applications, or other proprietary 419 rights that may cover technology that may be required to implement 420 this standard. Please address the information to the IETF at 421 ietf-ipr@ietf.org. 423 Acknowledgment 425 Funding for the RFC Editor function is provided by the IETF 426 Administrative Support Activity (IASA).