idnits 2.17.00 (12 Aug 2021) /tmp/idnits23983/draft-froment-sipping-spit-requirements-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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 433. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 440. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 446. 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 (June 14, 2007) is 5454 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4474' is mentioned on line 354, but not defined ** Obsolete undefined reference: RFC 4474 (Obsoleted by RFC 8224) == Missing Reference: 'RFC3693' is mentioned on line 343, but not defined == Missing Reference: 'RFC4412' is mentioned on line 350, but not defined == Missing Reference: 'I-D.ietf-ecrit-service-urn' is mentioned on line 311, but not defined == Missing Reference: 'I-D.rosenberg-sipping-service-identification' is mentioned on line 337, but not defined == Missing Reference: 'I-D.jennings-sip-hashcash' is mentioned on line 332, but not defined == Missing Reference: 'I-D.ietf-sip-consent-framework' is mentioned on line 326, but not defined == Missing Reference: 'RFC3880' is mentioned on line 346, but not defined == Missing Reference: 'I-D.ietf-sieve-3028bis' is mentioned on line 316, but not defined == Missing Reference: 'RFC4745' is mentioned on line 358, but not defined == Missing Reference: 'I-D.ietf-simple-presence-rules' is mentioned on line 321, but not defined Summary: 2 errors (**), 0 flaws (~~), 12 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: December 16, 2007 University of Namur 6 T. Froment 7 Alcatel-Lucent 8 D. Wing 9 Cisco 10 H. Schulzrinne 11 Columbia University 12 June 14, 2007 14 Requirements for Authorization Policies to tackle Spam for Internet 15 Telephony and Unwanted Traffic 16 draft-froment-sipping-spit-requirements-00.txt 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 December 16, 2007. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 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. 62 This document discusses the requirements to define authorization 63 policies that should allow end users or other parties to setup anti- 64 SPIT policies for triggering these actions. These policies typically 65 match a particular SIP communication pattern based on a number of 66 attributes. The range of attributes includes information provided, 67 for example, by the SIP protocol itself, by the SIP identity 68 mechanism, by information carried within SAML assertions, reputation 69 systems of social networks and other extensions. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3.3. Transformations . . . . . . . . . . . . . . . . . . . . . 8 79 3.4. Generic Requirements . . . . . . . . . . . . . . . . . . . 8 80 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 87 Intellectual Property and Copyright Statements . . . . . . . . . . 17 89 1. Introduction 91 The problem of SPIT is an important challenge and it appears that a 92 combination of several techniques is desirable to provide a framework 93 to deal with it. 95 One important building block is to provide a mechanism to instruct a 96 trusted SIP proxy or any other SIP element to influence message 97 handling of incoming requests according to policies. Different 98 entities, such as end users, parents on behalf of their kids or 99 system administrators, might create and modify authorization 100 policies. 102 Some attributes in an incoming message play a more important role 103 than others. For example, applying authorization policies based on 104 the authenticated identity, see [RFC4474], is an effective way to 105 make decisions regarding unwanted traffic in many cases. 107 This document identifies requirements for authorization policies when 108 used to influence message handling for unwanted communicaion 109 attempts. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119], 116 with the important qualification that, unless otherwise stated, these 117 terms apply to the design of the authorization policies, not its 118 implementation or application. 120 The term 'Rule Maker' is defined in RFC 3693 [RFC3693]. 122 3. Requirements 124 This section lists the requirements categorized according to their 125 applicability for the "conditions", "actions" and "transformation" 126 parts of authorization policies. Furthermore, we describe 127 requirements that are more generic in nature and apply to the entire 128 rule set. 130 3.1. Conditions 132 The first set of requirements refer to identity related information. 134 Req-C 1: Policies MUST allow conditions to express single 135 authenticated identities. 137 Req-C 2: Policies MUST allow filtering based on the domain part of 138 the identity. 140 Req-C 3: Policies MUST support the differentiation between 141 authenticated and unauthenticated identities. 143 Req-C 4: Policies MUST be able to express expections within a group 144 of users/domain. 146 Message handling might be different depending on the content of the 147 SIP message header fields. 149 Req-C 5: Policies SHOULD allow conditions to refer to the 150 "destination" (which corresponds to the "Request-URI") and 151 "original-destination" (which corresponds to the "To" header). 153 Req-C 6: Policies SHOULD allow conditions to refer to the method 154 invoked by the caller (e.g., INVITE, REFER, MESSAGE). 155 Motivation: Some SIP methods are more intrusive than others 156 (the default applicative behaviour when SIP MESSAGEs are 157 received is often to pop-up the message on the UAS side), 158 adopting a different filtering policy depending of the method 159 invoked will enhance the user's protection. 161 Req-C 7: Policies SHOULD allow Rule Makers to take actions on 162 messages that are marked as Spam. 164 Note that such a condition element should be seen in 165 context of the authenticated domain or or otherwise 166 protected information to avoid security 167 vulnerabilities. 169 [Editor's Note: Should we allow message handling based on the 170 existence or non-existence of certain SDP / SIP content, such as 171 specific mime types? For example, is a "exists" test useful that 172 returns true if the headers listed in the argument exist within the 173 message. Furthermore, do we need test operators (such as "allof" and 174 "anyof", which implement logical "and" and logical "or", 175 respectively)? 177 Message handling might be different based on time. 179 Req-C 7: Policies SHOULD allow conditions that refer to the 180 reception date, time or period of time of the incoming 181 request. 183 Message handling might be different based on the language. 185 Req-C 8: Policies SHOULD allow to make decisions based on the 186 languages in which the originator of the call wishes to 187 communicate. 189 Message handling might be different based on the SIP resource 190 priority fields, on emergency service related messages or more 191 generic forms of indicating the type of service. 193 Req-C 9: Policies MAY allow to make decisions based on the presence 194 of SIP Resouce Priority headers, as described in [RFC4412]. 196 Req-C 10: Policies SHOULD allow to make decisions based on the 197 messages marked as emergency calls indicated in 198 [I-D.ietf-ecrit-service-urn]. 200 Req-C 11: Policies MAY allow to make decisions based on service 201 identification fields, see 202 [I-D.rosenberg-sipping-service-identification]. 204 3.2. Actions 206 Req-A 1: Policies SHOULD allow messages to get "blocked", i.e., to 207 stop forwarding the request and to return an answer with a 208 ``403 Forbidden'' 210 Req-A 2: Policies SHOULD allow messages to get "politely blocked", 211 i.e., to drop the request without returning an answer. 213 Req-A 2: Policies SHOULD allow messages to get "marked", i.e., to 214 forward the request and mark it as "potential Spam" for 215 filtering at the end point or at subsequent entities along the 216 signaling path. 218 Req-A 3: Policies SHOULD allow messages to be "allowed", i.e., to 219 forward this message. 221 Req-A 4: Policies MUST allow messages to be "redirected" to, for 222 example, voicemail or to a different device in the possession 223 of the user. 225 Req-A 5: Policies MUST allow the ability to execute other SPIT 226 prevention procedures, such as computational puzzles 227 [I-D.jennings-sip-hashcash] or the consent framework" 228 [I-D.ietf-sip-consent-framework]. Ideally, a specification 229 developing a SPIT prevention mechanism SHOULD provide 230 information on how they can be incorporated into the 231 authorization policy framework. 233 As an example, for a statistical analysis tool a URI is 234 defined. The algorithms itself do not need to be 235 standardized and hence the impact for authorization 236 policies is mainly the ability to allow a Rule Maker to 237 enable or to disable the usage of these statistical 238 techniques for SPIT filtering and potentially to map 239 the output of the analysis process to value range from 240 0 (i.e., the message is not classified as Spam) and 100 241 (i.e., the message was classified as as Spam). A Rule 242 Maker may decide the appropriate action on the message 243 depending on the determined SPIT probability. 245 Req-A 6: Policies MAY allow an e-mail (or SMS, MMS) to be sent to 246 the user about the actions taken due to a specific call 247 attempt. 249 3.3. Transformations 251 Req-T 1: Policies SHOULD allow SIP messages to be marked with a 252 certain SPIT probability in case SPIT detection and policy 253 enforcement is excecuted on different entities. For example, 254 a network element might run a statistical SPIT detection tool 255 but the authorization policies are executed on a different 256 entity, such as the end host. Note that it needs to be 257 ensured that an adversary is not able to set the SPIT 258 probabity values since otherwise the authorization policies 259 that rely on such information are misguided. 261 3.4. Generic Requirements 262 Req-G 1: It SHOULD be possible to allow a hierarchy of authorization 263 policies to be used. 265 Req-G 2: It MUST be possible for a client to learn the supported 266 authorization policy capabilities implemented by the server. 268 Req-G 3: Policies MUST be extensible and these extensions MUST exist 269 within a different namespace. Furthermore, a published schema 270 and the namespace for elements defined within it MUST NOT be 271 altered by future specifications. 273 Req-G 4: The policies MUST provide a mandatory-to-implement conflict 274 resolution mechanism. 276 4. IANA Considerations 278 This document does not require actions by IANA. 280 5. Security Considerations 282 This document describes the requirements for elements contained in 283 the authorization policies that allow communication attempts to be 284 treated differently based on the content of the message, time-of-day, 285 context of the user, reputation of the sending party, and many other 286 factors. 288 The security concerns are related to the ability of certain entities 289 to create, update and delete authorization policies. If an 290 unauthorized entity is allowed to modify policies (and to distribute 291 them to other domains) then a denial of service attack is the 292 consequence with impact for more than a single end point. These 293 security aspects are, however, not subject of this document. 295 6. Acknowledgements 297 The content of this document is inspired by the work of CPL 298 [RFC3880], SIEVE [I-D.ietf-sieve-3028bis], Common Policy [RFC4745] 299 and Presence Authorization Policy [I-D.ietf-simple-presence-rules]. 300 We would like to thank the authors of these documents for their work. 302 7. References 304 7.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 7.2. References 311 [I-D.ietf-ecrit-service-urn] 312 Schulzrinne, H., "A Uniform Resource Name (URN) for 313 Services", draft-ietf-ecrit-service-urn-06 (work in 314 progress), March 2007. 316 [I-D.ietf-sieve-3028bis] 317 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 318 Language", draft-ietf-sieve-3028bis-12 (work in progress), 319 February 2007. 321 [I-D.ietf-simple-presence-rules] 322 Rosenberg, J., "Presence Authorization Rules", 323 draft-ietf-simple-presence-rules-09 (work in progress), 324 March 2007. 326 [I-D.ietf-sip-consent-framework] 327 Rosenberg, J., "A Framework for Consent-Based 328 Communications in the Session Initiation Protocol (SIP)", 329 draft-ietf-sip-consent-framework-01 (work in progress), 330 November 2006. 332 [I-D.jennings-sip-hashcash] 333 Jennings, C., "Computational Puzzles for SPAM Reduction in 334 SIP", draft-jennings-sip-hashcash-05 (work in progress), 335 June 2007. 337 [I-D.rosenberg-sipping-service-identification] 338 Rosenberg, J., "Identification of Communications Services 339 in the Session Initiation Protocol (SIP)", 340 draft-rosenberg-sipping-service-identification-02 (work in 341 progress), May 2007. 343 [RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and 344 J. Polk, "Geopriv Requirements", RFC 3693, February 2004. 346 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 347 Language (CPL): A Language for User Control of Internet 348 Telephony Services", RFC 3880, October 2004. 350 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 351 Priority for the Session Initiation Protocol (SIP)", 352 RFC 4412, February 2006. 354 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 355 Authenticated Identity Management in the Session 356 Initiation Protocol (SIP)", RFC 4474, August 2006. 358 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 359 Polk, J., and J. Rosenberg, "Common Policy: A Document 360 Format for Expressing Privacy Preferences", RFC 4745, 361 February 2007. 363 Authors' Addresses 365 Hannes Tschofenig (editor) 366 Nokia Siemens Networks 367 Otto-Hahn-Ring 6 368 Munich, Bavaria 81739 369 Germany 371 Email: Hannes.Tschofenig@nsn.com 372 URI: http://www.tschofenig.com 374 Geoffrey Dawirs 375 University of Namur 376 21, rue Grandgagnage 377 Namur B-5000 378 Belgique 380 Email: gdawirs@gdawirs.be 382 Thomas Froment 383 Alcatel-Lucent 384 Route de Villejust 385 Nozay, Paris 91620 386 France 388 Email: Thomas.Froment@alcatel-lucent.fr 390 Dan Wing 391 Cisco 392 170 West Tasman Drive 393 San Jose, CA 95134 394 USA 396 Email: dwing@cisco.com 397 Henning Schulzrinne 398 Columbia University 399 Department of Computer Science 400 450 Computer Science Building 401 New York, NY 10027 402 US 404 Phone: +1 212 939 7004 405 Email: hgs@cs.columbia.edu 406 URI: http://www.cs.columbia.edu 408 Full Copyright Statement 410 Copyright (C) The IETF Trust (2007). 412 This document is subject to the rights, licenses and restrictions 413 contained in BCP 78, and except as set forth therein, the authors 414 retain all their rights. 416 This document and the information contained herein are provided on an 417 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 418 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 419 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 420 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 421 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 422 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 424 Intellectual Property 426 The IETF takes no position regarding the validity or scope of any 427 Intellectual Property Rights or other rights that might be claimed to 428 pertain to the implementation or use of the technology described in 429 this document or the extent to which any license under such rights 430 might or might not be available; nor does it represent that it has 431 made any independent effort to identify any such rights. Information 432 on the procedures with respect to rights in RFC documents can be 433 found in BCP 78 and BCP 79. 435 Copies of IPR disclosures made to the IETF Secretariat and any 436 assurances of licenses to be made available, or the result of an 437 attempt made to obtain a general license or permission for the use of 438 such proprietary rights by implementers or users of this 439 specification can be obtained from the IETF on-line IPR repository at 440 http://www.ietf.org/ipr. 442 The IETF invites any interested party to bring to its attention any 443 copyrights, patents or patent applications, or other proprietary 444 rights that may cover technology that may be required to implement 445 this standard. Please address the information to the IETF at 446 ietf-ipr@ietf.org. 448 Acknowledgment 450 Funding for the RFC Editor function is provided by the IETF 451 Administrative Support Activity (IASA).