idnits 2.17.1 draft-ietf-sipcore-status-unwanted-02.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 183 has weird spacing: '... Name sip.6...' -- The document date (January 12, 2017) is 2659 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) ** Downref: Normative reference to an Informational RFC: RFC 5057 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-15 Summary: 1 error (**), 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 12, 2017 5 Expires: July 16, 2017 7 A SIP Response Code for Unwanted Calls 8 draft-ietf-sipcore-status-unwanted-02 10 Abstract 12 This document defines the 666 (Unwanted) SIP response code, allowing 13 called parties to indicate that the call or message was unwanted. 14 SIP entities may use this information to adjust how future calls from 15 this calling 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 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . 5 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 8.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 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 session with a BYE request after answering the call. 79 To 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 As in [I-D.ietf-stir-rfc4474bis], we use the term "caller identity" 86 or "calling party identity" in this document to mean either a 87 canonical address-of-record (AoR) SIP URI employed to reach a user 88 (such as 'sip:alice@atlanta.example.com'), or a telephone number, 89 which commonly appears in either a tel URI [RFC3966] or as the user 90 portion of a SIP URI. 92 2. Normative Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in BCP 14, RFC 2119 97 [RFC2119]. 99 3. Motivation 101 None of the existing 4xx, 5xx or 6xx response codes signify that this 102 SIP request is unwanted by the called party. The particular response 103 code number was chosen to reflect the distaste felt by many upon 104 receiving such calls. 106 4. Behavior of SIP Entities 108 The response code 666 MAY be used in a failure response for an 109 INVITE, MESSAGE, SUBSCRIBE or other out-of-dialog SIP request to 110 indicate that the offered communication is unwanted. The response 111 code MAY also be used as the value of the "cause" parameter of a SIP 112 reason-value in a Reason header field [RFC3326], typically when the 113 UAS issues a BYE request terminating an incoming call or the UAC 114 issues a CANCEL request when forking a call. (Including a Reason 115 header field with the 666 status code allows the UAS that receive a 116 CANCEL request to make an informed choice whether and how to include 117 such calls in their missed-call list.) 119 The SIP entities receiving this response code are not obligated to 120 take any particular action beyond those appropriate for 6xx 121 responses. Following the default handling for 6xx responses in 122 [RFC5057], the 666 response destroys the transaction. The service 123 provider delivering calls or messages to the user issuing the 124 response, for example, MAY add the calling party to a personal 125 blacklist specific to the called party, MAY use the information as 126 input when computing the likelihood that the calling party is placing 127 unwanted calls ("crowd sourcing"), MAY initiate a traceback request, 128 and MAY report the calling party identity to government authorities. 130 Systems receiving 666 responses could decide to treat pre-call and 131 mid-call responses differently, given that the called party has had 132 access to call content for mid-call rejections. In other words, 133 depending on the implementation, the response code does not 134 necessarily automatically block all calls from that caller identity. 135 The same user interface action might also trigger addition of the 136 caller identity to a local, on-device blacklist or graylist, e.g., 137 causing such calls to be flagged or alerted with a different ring 138 tone. 140 The actions described here do not depend on the nature of the SIP 141 URI, e.g., whether it describes a telephone number or not; however, 142 the same anonymous SIP URI [RFC3323] may be used by multiple callers 143 and thus such URIs are unlikely to be appropriate for URI-specific 144 call treatment. SIP entities tallying responses for particular 145 callers may need to consider canonicalzing SIP URIs, including 146 telephone numbers, as described in [I-D.ietf-stir-rfc4474bis]. The 147 calling party may be identified in different locations in the SIP 148 header, e.g., the From header field, P-Asserted-Identity or History- 149 Info, and may also be affected by diverting services. 151 This document defines a SIP feature-capability [RFC6809], sip.666, 152 that allows the registrar to indicate that the corresponding proxy 153 supports this particular response code. This allows the UA, for 154 example, to provide a suitable user interface element, such as a 155 "spam" button, only if its service provider actually supports the 156 feature. The presence of the feature capability does not imply that 157 the provider will take any particular action, such as blocking future 158 calls. A UA may still decide to render a "spam" button even without 159 such as a capability if, for example, it maintains a device-local 160 blacklist or reports unwanted calls to a third party. 162 5. IANA Considerations 164 5.1. SIP Response Code 166 This document registers a new SIP response code. This response code 167 is defined by the following information, which is to be added to the 168 "Response Codes" sub-registry under http://www.iana.org/assignments/ 169 sip-parameters. 171 Response Code Number 666 173 Default Reason Phrase Unwanted 175 Reference [this RFC] 177 5.2. SIP Global Feature-Capability Indicator 179 This document defines the feature capability sip.666 in the "SIP 180 Feature-Capability Indicator Registration Tree" registry defined in 181 [RFC6809]. 183 Name sip.666 185 Description This feature-capability indicator when used in a 186 REGISTER response indicates that the server will process the 666 187 response code. This does not imply any specific action. 189 Reference [this RFC] 191 6. Security Considerations 193 If the calling party address is spoofed, users may report the caller 194 identity as placing unwanted calls, possibly leading to the blocking 195 of calls from the legitimate user of the caller identity in addition 196 to the unwanted caller, i.e., creating a form of denial-of-service 197 attack. Thus, the response code SHOULD NOT be used for creating 198 global call filters unless the calling party identity has been 199 authenticated using [I-D.ietf-stir-rfc4474bis] as being assigned to 200 the caller placing the unwanted call. (The creation of call filters 201 local to a user agent is beyond the scope of this document.) 203 Even if the identity is not spoofed, a call or message recipient 204 might flag legitimate caller identities, e.g., to extract vengeance 205 on a person or business, or simply by mistake. To correct errors, 206 any additions to a personal list of blocked caller identities should 207 be observable and reversible by the party being protected by the 208 blacklist. For example, the list may be shown on a web page or the 209 subscriber may be notified by periodic email reminders. Any 210 additions to a global or carrier-wide list of unwanted callers needs 211 to consider that any user-initiated mechanism will suffer from an 212 unavoidable rate of false positives and tailor their algorithms 213 accordingly, e.g., by comparing the fraction of delivered calls for a 214 particular caller that are flagged as unwanted rather than just the 215 absolute number, and considering time-weighted filters that give more 216 credence to recent feedback. 218 Since caller identities are routinely re-assigned to new subscribers, 219 algorithms are advised to consider whether the caller identity has 220 been re-assigned to a new subscriber and possibly reset any related 221 rating. 223 For both individually-authenticated and unauthenticated calls, 224 recipients of response code 666 may want to distinguish responses 225 sent before and after the call has been answered, ascertaining 226 whether either response timing suffers from a lower false-positive 227 rate. 229 7. Acknowledgements 231 Tolga Asveren, Peter Dawes, Martin Dolly, Keith Drage, Vijay Gurbani, 232 Olle Johansson, Paul Kyzivat, Jean Mahoney, Marianne Mohali, Brian 233 Rosen, Brett Tate, Chris Wendt and Dale Worley provided helpful 234 comments. 236 8. References 238 8.1. Normative References 240 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 241 Requirement Levels", BCP 14, RFC 2119, 242 DOI 10.17487/RFC2119, March 1997, 243 . 245 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 246 A., Peterson, J., Sparks, R., Handley, M., and E. 247 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 248 DOI 10.17487/RFC3261, June 2002, 249 . 251 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 252 Header Field for the Session Initiation Protocol (SIP)", 253 RFC 3326, DOI 10.17487/RFC3326, December 2002, 254 . 256 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 257 Initiation Protocol", RFC 5057, DOI 10.17487/RFC5057, 258 November 2007, . 260 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 261 Indicate Support of Features and Capabilities in the 262 Session Initiation Protocol (SIP)", RFC 6809, 263 DOI 10.17487/RFC6809, November 2012, 264 . 266 8.2. Informative References 268 [I-D.ietf-stir-rfc4474bis] 269 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 270 "Authenticated Identity Management in the Session 271 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-15 272 (work in progress), October 2016. 274 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 275 Initiation Protocol (SIP)", RFC 3323, 276 DOI 10.17487/RFC3323, November 2002, 277 . 279 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 280 RFC 3966, DOI 10.17487/RFC3966, December 2004, 281 . 283 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 284 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 285 January 2008, . 287 Author's Address 289 Henning Schulzrinne 290 FCC 291 445 12th Street SW 292 Washington, DC 20554 293 US 295 Email: henning.schulzrinne@fcc.gov