idnits 2.17.00 (12 Aug 2021) /tmp/idnits23564/draft-froment-sipping-spit-requirements-02.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 393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 417. 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 25, 2008) is 5198 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC4474' is mentioned on line 325, but not defined ** Obsolete undefined reference: RFC 4474 (Obsoleted by RFC 8224) == Missing Reference: 'I-D.jennings-sip-hashcash' is mentioned on line 316, but not defined == Missing Reference: 'I-D.ietf-sip-consent-framework' is mentioned on line 310, but not defined == Missing Reference: 'RFC3880' is mentioned on line 321, but not defined == Missing Reference: 'I-D.ietf-sieve-3028bis' is mentioned on line 300, but not defined == Missing Reference: 'RFC4745' is mentioned on line 329, but not defined == Missing Reference: 'I-D.ietf-simple-presence-rules' is mentioned on line 305, but not defined Summary: 2 errors (**), 0 flaws (~~), 8 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: August 28, 2008 University of Namur 6 T. Froment 7 Alcatel-Lucent 8 D. Wing 9 Cisco 10 H. Schulzrinne 11 Columbia University 12 February 25, 2008 14 Requirements for Authorization Policies to tackle Spam and Unwanted 15 Communication for Internet Telephony 16 draft-froment-sipping-spit-requirements-02 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 August 28, 2008. 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, reputation 68 systems of social networks or other extensions. 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 The problem of SPIT is an important challenge and it is to expect 91 that a combination of several techniques is desirable to provide a 92 framework to deal with it. The goal of SPIT-policies is not to 93 discuss these techniques, or to propose new ones. It just suggest to 94 provide a way to define these policies using a standardized XML 95 format. 97 One important building block is to provide a mechanism to instruct a 98 trusted SIP proxy or any other SIP element to influence message 99 handling of incoming requests according to policies. Different 100 entities, such as end users, parents on behalf of their kids or 101 system administrators, might create, modify or delete authorization 102 policies. 104 Some attributes in an incoming message play a more important role 105 than others. For example, applying authorization policies based on 106 the authenticated identity, see [RFC4474], is an effective way to 107 make decisions regarding unwanted traffic in many cases. 109 This document identifies requirements for authorization policies when 110 used to influence message handling for unwanted communication 111 attempts. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in RFC 2119 [RFC2119], 118 with the important qualification that, unless otherwise stated, these 119 terms apply to the design of the authorization policies, not its 120 implementation or application. 122 3. Requirements 124 This section lists the requirements categorized according to their 125 applicability for the "conditions", "actions" and "transformation" 126 parts typically found in authorization policies. 128 3.1. Conditions 130 The first set of requirements refer to identity related information. 132 Req-C 1: Policies MUST allow conditions to express single 133 authenticated identities. 135 Req-C 2: Policies MUST allow filtering based on the domain part of 136 the identity. 138 Req-C 3: Policies MUST support the differentiation between 139 authenticated and unauthenticated identities. 141 Req-C 4: Policies MUST be able to express exceptions within a group 142 of users or a domain. 144 Req-C 5: Policies SHOULD allow an anonymous identity as a condition. 146 Message handling might be different depending on the content of the 147 SIP message header fields. 149 Req-C 6: 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 7: Policies SHOULD allow conditions to refer to the method 154 invoked by the caller (e.g., INVITE, REFER, MESSAGE, 155 SUBSCRIBE). 157 Motivation: Some SIP methods are more intrusive than others 158 (the default applicative behaviour when SIP MESSAGEs are 159 received is often to pop-up the message on the UAS side), 160 adopting a different filtering policy depending of the method 161 invoked will enhance the user's protection. 163 Req-C 8: Policies SHOULD allow the entity that writes the rules to 164 take actions on messages that are marked as Spam. 166 Note that such a condition element should be seen in 167 context of the authenticated domain or, otherwise, of a 168 protected information to avoid security 169 vulnerabilities. 171 Req-C 9: Policies MAY allow to make decisions based on the current 172 state of the user. E.g., based on a user who selected an 173 active profile, or sphere or another presence information. 175 Req-C 10: Policies SHOULD support consitions based on the content 176 type and/or offered (or used) media of a message. 178 Message handling might be different based on time/date. 180 Req-C 11: Policies SHOULD allow conditions that refer to the 181 reception date, time, timezone or period of time of the 182 incoming request. 184 Message handling might be different based on the language. 186 Req-C 12: Policies SHOULD allow to make decisions based on the 187 languages in which the originator of the call wishes to 188 communicate. 190 3.2. Actions 192 Req-A 1: Policies SHOULD allow messages to get "blocked", i.e., to 193 stop forwarding the request and to return an answer with a 194 "403 Forbidden'' 196 Req-A 2: Policies SHOULD allow messages to get "politely blocked", 197 i.e., to drop the request without returning any answer. 199 Req-A 3: Policies SHOULD allow messages to get "marked", i.e., to 200 forward the request and mark it as "potential Spam" for 201 filtering at the end point or at subsequent entities along the 202 signaling path. 204 Req-A 4: Policies SHOULD allow messages to be "allowed", i.e., to 205 forward this message. 207 Req-A 5: Policies MUST allow messages to be "redirected" to, for 208 example, voicemail or to a different device in the possession 209 of the user. 211 Req-A 6: Policies MUST allow executing other SPIT prevention 212 procedures, such as computational puzzles 213 [I-D.jennings-sip-hashcash] or the consent framework" 214 [I-D.ietf-sip-consent-framework]. A specification developing 215 a SPIT prevention mechanism should provide information on how 216 they can be incorporated into the authorization policy 217 framework. 219 Req-A 7: Policies MAY allow an e-mail (or SMS, MMS) or other 220 notifications to be sent to the user about the actions taken 221 due to a specific call attempt. 223 R8: Policies MAY allow the usage of one or many feedback 224 mechanisms. 226 3.3. Transformations 228 Req-T 1: Policies SHOULD allow SIP messages to be marked with a 229 certain SPIT probability in case SPIT detection and policy 230 enforcement is excecuted on different entities. For example, 231 a network element might run a statistical SPIT detection tool 232 but the authorization policies are executed on a different 233 entity, such as the end host. Note that it needs to be 234 ensured that an adversary is not able to set the SPIT 235 probabity values since otherwise the authorization policies 236 that rely on such information are misguided. 238 3.4. Generic Requirements 240 Req-G 1: It SHOULD be possible to allow a hierarchy of authorization 241 policies to be used. 243 It is quite likely that a rules from different rule writing 244 entities are provided. For example, in a company environment 245 policies from the system administrator are provided in 246 addition to the end users policies. The former might reflect 247 the overall company policy. The impact for the policy is 248 mainly on the definition of an appropriate conflict resolution 249 mechanism. 251 Req-G 2: It MUST be possible for a client to learn the supported 252 authorization policy capabilities implemented by the server. 254 Req-G 3: Policies MUST be extensible and these extensions MUST exist 255 within a different namespace. Furthermore, a published schema 256 and the namespace for elements defined within it MUST NOT be 257 altered by future specifications. 259 Req-G 4: The policies MUST provide a mandatory-to-implement conflict 260 resolution mechanism. 262 4. IANA Considerations 264 This document does not require actions by IANA. 266 5. Security Considerations 268 This document describes the requirements for elements contained in 269 the authorization policies that allow communication attempts to be 270 treated differently based on the content of the message, time-of-day, 271 context of the user, reputation of the sending party, and many other 272 factors. 274 The security concerns are related to the ability of certain entities 275 to create, update and delete authorization policies. If an 276 unauthorized entity is allowed to modify policies (and to distribute 277 them to other domains) then a denial of service attack is the 278 consequence with impact for more than a single end point. These 279 security aspects are, however, not subject of this document. 281 6. Acknowledgements 283 The content of this document is inspired by the work of CPL 284 [RFC3880], SIEVE [I-D.ietf-sieve-3028bis], Common Policy [RFC4745] 285 and Presence Authorization Policy [I-D.ietf-simple-presence-rules]. 286 We would like to thank the authors of these documents for their work. 288 Furthermore, we would like to thank Eva Leppanen for the detailed 289 review provided in June 2006. 291 7. References 293 7.1. Normative References 295 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 296 Requirement Levels", BCP 14, RFC 2119, March 1997. 298 7.2. References 300 [I-D.ietf-sieve-3028bis] 301 Showalter, T. and P. Guenther, "Sieve: An Email Filtering 302 Language", draft-ietf-sieve-3028bis-13 (work in progress), 303 October 2007. 305 [I-D.ietf-simple-presence-rules] 306 Rosenberg, J., "Presence Authorization Rules", 307 draft-ietf-simple-presence-rules-10 (work in progress), 308 July 2007. 310 [I-D.ietf-sip-consent-framework] 311 Rosenberg, J., Camarillo, G., and D. Willis, "A Framework 312 for Consent-based Communications in the Session Initiation 313 Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work 314 in progress), January 2008. 316 [I-D.jennings-sip-hashcash] 317 Jennings, C., "Computational Puzzles for SPAM Reduction in 318 SIP", draft-jennings-sip-hashcash-06 (work in progress), 319 July 2007. 321 [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing 322 Language (CPL): A Language for User Control of Internet 323 Telephony Services", RFC 3880, October 2004. 325 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 326 Authenticated Identity Management in the Session 327 Initiation Protocol (SIP)", RFC 4474, August 2006. 329 [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., 330 Polk, J., and J. Rosenberg, "Common Policy: A Document 331 Format for Expressing Privacy Preferences", RFC 4745, 332 February 2007. 334 Authors' Addresses 336 Hannes Tschofenig (editor) 337 Nokia Siemens Networks 338 Otto-Hahn-Ring 6 339 Munich, Bavaria 81739 340 Germany 342 Email: Hannes.Tschofenig@nsn.com 343 URI: http://www.tschofenig.com 345 Geoffrey Dawirs 346 University of Namur 347 21, rue Grandgagnage 348 Namur B-5000 349 Belgique 351 Email: gdawirs@gdawirs.be 353 Thomas Froment 354 Alcatel-Lucent 355 Route de Villejust 356 Nozay, Paris 91620 357 France 359 Email: Thomas.Froment@alcatel-lucent.fr 361 Dan Wing 362 Cisco 363 170 West Tasman Drive 364 San Jose, CA 95134 365 USA 367 Email: dwing@cisco.com 368 Henning Schulzrinne 369 Columbia University 370 Department of Computer Science 371 450 Computer Science Building 372 New York, NY 10027 373 US 375 Phone: +1 212 939 7004 376 Email: hgs@cs.columbia.edu 377 URI: http://www.cs.columbia.edu 379 Full Copyright Statement 381 Copyright (C) The IETF Trust (2008). 383 This document is subject to the rights, licenses and restrictions 384 contained in BCP 78, and except as set forth therein, the authors 385 retain all their rights. 387 This document and the information contained herein are provided on an 388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 390 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 391 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 392 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 Intellectual Property 397 The IETF takes no position regarding the validity or scope of any 398 Intellectual Property Rights or other rights that might be claimed to 399 pertain to the implementation or use of the technology described in 400 this document or the extent to which any license under such rights 401 might or might not be available; nor does it represent that it has 402 made any independent effort to identify any such rights. Information 403 on the procedures with respect to rights in RFC documents can be 404 found in BCP 78 and BCP 79. 406 Copies of IPR disclosures made to the IETF Secretariat and any 407 assurances of licenses to be made available, or the result of an 408 attempt made to obtain a general license or permission for the use of 409 such proprietary rights by implementers or users of this 410 specification can be obtained from the IETF on-line IPR repository at 411 http://www.ietf.org/ipr. 413 The IETF invites any interested party to bring to its attention any 414 copyrights, patents or patent applications, or other proprietary 415 rights that may cover technology that may be required to implement 416 this standard. Please address the information to the IETF at 417 ietf-ipr@ietf.org. 419 Acknowledgment 421 Funding for the RFC Editor function is provided by the IETF 422 Administrative Support Activity (IASA).