idnits 2.17.1 draft-ietf-sipcore-status-unwanted-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == Line 166 has weird spacing: '... Name sip.6...' -- The document date (January 4, 2017) is 2668 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) == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-15 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE H. Schulzrinne 3 Internet-Draft FCC 4 Intended status: Standards Track January 4, 2017 5 Expires: July 8, 2017 7 A SIP Response Code for Unwanted Calls 8 draft-ietf-sipcore-status-unwanted-01 10 Abstract 12 This document defines the 666 (Unwanted) SIP response code, allowing 13 called parties to indicate that the call was unwanted. SIP entities 14 may use this information to adjust how future calls from this calling 15 party are handled for the called party or more broadly. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 8, 2017. 34 Copyright Notice 36 Copyright (c) 2017 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 2 53 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 4. Behavior of SIP Entities . . . . . . . . . . . . . . . . . . 3 55 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 56 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 4 57 5.2. SIP Global Feature-Capability Indicator . . . . . . . . . 4 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 8.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 In many countries, an increasing number of calls are unwanted 68 [RFC5039]: they might be fraudulent, illegal telemarketing or the 69 receiving party does not want to be disturbed by, say, surveys or 70 solicitation by charities. Carriers and other service providers may 71 want to help their subscribers avoid receiving such calls, using a 72 variety of global or user-specific filtering algorithms. One input 73 into such algorithms is user feedback. User feedback may be offered 74 through smartphone apps, APIs or within the context of a SIP- 75 initiated call. This document addresses only the last mode, where 76 the called party either rejects the SIP [RFC3261] request, typically 77 requests using the INVITE or MESSAGE methods, as unwanted or 78 terminates the call with a BYE request after answering the call. To 79 allow the called party to express that the call was unwanted, this 80 document defines the 666 (Unwanted) response code. The called user 81 agent (UAS), based on input from the called party or some UA-internal 82 logic, uses this to indicate that future calls from the same caller 83 are also unwanted. 85 2. Normative Language 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in BCP 14, RFC 2119 90 [RFC2119]. 92 3. Motivation 94 None of the existing 4xx, 5xx or 6xx response codes signify that 95 calls from this caller are unwanted by the called party. The 96 particular response code number was chosen to reflect the distaste 97 felt by many upon receiving such calls. 99 4. Behavior of SIP Entities 101 The response code 666 MAY be used in a failure response for an 102 INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to 103 indicate that the offered communication is unwanted. The response 104 code MAY also be used as the value of the "cause" parameter of a SIP 105 reason-value in a Reason header field [RFC3326], typically when the 106 UAS issues a BYE or CANCEL request terminating an incoming call. 108 The SIP entities receiving this response code are not obligated to 109 take any particular action. The service provider delivering calls to 110 the user issuing the response, for example, MAY add the calling party 111 to a personal blacklist specific to the called party, MAY use the 112 information as input when computing the likelihood that the calling 113 party is placing unwanted calls ("crowd sourcing"), MAY initiate a 114 traceback request, and MAY report the calling number to government 115 authorities. 117 Receiving systems could decide to treat pre-call and mid-call 118 responses differently, given that the called party has had access to 119 call content for mid-call rejections. In other words, depending on 120 the implementation, the response code does not necessarily 121 automatically block all calls from that number. The same user 122 interface action might also trigger addition of the number to a 123 local, on-device blacklist or graylist, e.g., causing such calls to 124 be flagged or alerted with a different ring tone. 126 The actions described here do not depend on the nature of the SIP 127 URI, e.g., whether it describes a telephone number or not; however, 128 the same anonymous SIP URI [RFC3323] may be used by multiple callers 129 and thus such URIs are unlikely to be appropriate for URI-specific 130 call treatment. SIP entities tallying responses for particular 131 callers may need to consider canonicalzing SIP URIs, including 132 telephone numbers, as described in [I-D.ietf-stir-rfc4474bis]. 134 We define a SIP feature-capability [RFC6809], sip.666, that allows 135 the registrar to indicate that the corresponding proxy supports this 136 particular response code. This allows the UA, for example, to 137 provide a suitable user interface element, such as a "spam" button, 138 only if its service provider actually supports the feature. The 139 presence of the feature capability does not imply that the provider 140 will take any particular action, such as blocking future calls. A UA 141 may still decide to render a "spam" button even without such as a 142 capability if, for example, it maintains a device-local blacklist or 143 reports unwanted calls to a third party. 145 5. IANA Considerations 147 5.1. SIP Response Code 149 This document registers a new SIP response code. This response code 150 is defined by the following information, which is to be added to the 151 "Response Codes" sub-registry under http://www.iana.org/assignments/ 152 sip-parameters. 154 Response Code Number 666 156 Default Reason Phrase Unwanted 158 Reference [this RFC] 160 5.2. SIP Global Feature-Capability Indicator 162 This document defines the feature capability sip.666 in the "SIP 163 Feature-Capability Indicator Registration Tree" registry defined in 164 [RFC6809]. 166 Name sip.666 168 Description This feature-capability indicator when used in a 169 REGISTER response indicates that the server will process the 666 170 response code. This does not imply any specific action. 172 Reference [this RFC] 174 6. Security Considerations 176 If the calling party number is spoofed, users may report the number 177 as placing unwanted calls, possibly leading to the blocking of calls 178 from the legitimate user of the number in addition to the unwanted 179 caller, i.e., creating a form of denial-of-service attack. Thus, the 180 response code SHOULD NOT be used for creating global call filters 181 unless the calling party number has been authenticated using 182 [I-D.ietf-stir-rfc4474bis] as being assigned to the caller placing 183 the unwanted call. (The creation of call filters local to a user 184 agent is beyond the scope of this document.) 186 Even if the number is not spoofed, a call recipient might flag 187 legitimate numbers, e.g., to extract vengeance on a person or 188 business, or simply by mistake. To correct errors, any additions to 189 a personal list of blocked numbers should be observable and 190 reversible by the party being protected by the blacklist. For 191 example, the list may be shown on a web page or the subscriber may be 192 notified by periodic email reminders. Any additions to a global or 193 carrier-wide list of unwanted callers needs to consider that any 194 user-initiated mechanism will suffer from an unavoidable rate of 195 false positives and tailor their algorithms accordingly, e.g., by 196 comparing the fraction of delivered calls for a particular caller 197 that are flagged as unwanted rather than just the absolute number, 198 and considering time-weighted filters that give more credence to 199 recent feedback. 201 Since telephone numbers are routinely re-assigned to new subscribers, 202 algorithms are advised to consider whether the number has been re- 203 assigned to a new subscriber and possibly reset any related rating. 205 For both individually-authenticated and unauthenticated calls, 206 recipients may want to distinguish responses sent before and after 207 the call has been answered, ascertaining whether either response 208 timing suffers from a lower false-positive rate. 210 7. Acknowledgements 212 Tolga Asveren, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani, 213 Paul Kyzivat, Jean Mahoney, Brian Rosen, Chris Wendt and Dale Worley 214 provided helpful comments. 216 8. References 218 8.1. Normative References 220 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", BCP 14, RFC 2119, 222 DOI 10.17487/RFC2119, March 1997, 223 . 225 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 226 A., Peterson, J., Sparks, R., Handley, M., and E. 227 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 228 DOI 10.17487/RFC3261, June 2002, 229 . 231 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 232 Header Field for the Session Initiation Protocol (SIP)", 233 RFC 3326, DOI 10.17487/RFC3326, December 2002, 234 . 236 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 237 Indicate Support of Features and Capabilities in the 238 Session Initiation Protocol (SIP)", RFC 6809, 239 DOI 10.17487/RFC6809, November 2012, 240 . 242 8.2. Informative References 244 [I-D.ietf-stir-rfc4474bis] 245 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 246 "Authenticated Identity Management in the Session 247 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-15 248 (work in progress), October 2016. 250 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 251 Initiation Protocol (SIP)", RFC 3323, 252 DOI 10.17487/RFC3323, November 2002, 253 . 255 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 256 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 257 January 2008, . 259 Author's Address 261 Henning Schulzrinne 262 FCC 263 445 12th Street SW 264 Washington, DC 20554 265 US 267 Email: henning.schulzrinne@fcc.gov