idnits 2.17.1 draft-ietf-sipcore-callinfo-spam-04.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 30 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 358 has weird spacing: '... Name sip.c...' -- The document date (August 29, 2019) is 1701 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 3324 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 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 Columbia University 4 Intended status: Standards Track August 29, 2019 5 Expires: March 1, 2020 7 SIP Call-Info Parameters for Labeling Calls 8 draft-ietf-sipcore-callinfo-spam-04 10 Abstract 12 Called parties often wish to decide whether to accept, reject or 13 redirect calls based on the likely nature of the call. For example, 14 they may want to reject unwanted telemarketing or fraudulent calls, 15 but accept emergency alerts from numbers not in their address book. 16 This document describes SIP Call-Info parameters and a feature tag 17 that allow originating, intermediate and terminating SIP entities to 18 label calls as to their type, confidence and references to additional 19 information. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 1, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Normative Language . . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 58 4. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Call Types . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. REGISTER Response . . . . . . . . . . . . . . . . . . . . 7 62 6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . 7 63 7. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 8.1. SIP Call-Info Header Field Parameters . . . . . . . . . . 8 66 8.2. SIP Global Feature-Capability Indicator . . . . . . . . . 8 67 8.3. SIP Call-Info Type Parameter . . . . . . . . . . . . . . 8 68 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 70 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 11.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 75 1. Introduction 77 In many countries, an increasing number of calls are unwanted 78 [RFC5039], as they might be fraudulent, telemarketing or the 79 receiving party does not want to be disturbed by, say, surveys or 80 solicitation by charities. Currently, called parties have to rely 81 exclusively on the caller's number or, if provided, caller name, but 82 unwanted callers may not provide their true name or may use a name 83 that misleads, e.g., "Cardholder Services". On the other hand, many 84 calls from unknown numbers may be important to the called party, 85 whether this is an emergency alert from their emergency management 86 office or a reminder about a doctor's appointment. Since many 87 subscribers now reject all calls from unknown numbers, such calls may 88 also inadvertently be left unanswered. Users may also install 89 smartphone apps that can benefit from additional information in 90 making decisions as to whether to ring, reject or redirect a call to 91 voicemail. 93 To allow called parties to make more informed decisions on how to 94 handle incoming calls from unknown callers, we describe a new set of 95 parameters for the SIP [RFC3261] Call-Info header field for labeling 96 the nature of the call. 98 This specification assumes that the user agent can trust its SIP 99 provider to correctly label the nature of calls. This may not always 100 be the case and not all SIP service providers will label calls, so 101 users may need to draw on other, third-party, sources of call 102 information beyond the scope of this specification or may decide to 103 disregard the call labeling offered by their service provider. 104 (Service providers may, for example, be reluctant to label calls as 105 spam.) However, the SIP registrar already occupies a position of 106 trust by necessity; also, the user agent is typically a customer of 107 the operator of the registrar or within the same organization, e.g., 108 if the registrar is part of a PBX. Thus, the entity inserting the 109 Call-Info header field and the UAS relying on it SHOULD be part of 110 the same trust domain [RFC3324]. Conversely, the entity signing the 111 caller information [RFC8224] is likely either to be the caller itself 112 or the originating service provider, neither of which is likely to 113 label the caller as a category unlikely to be answered by the called 114 party. 116 The service provider inserting the Call-Info header field may draw on 117 a wide variety of sources. For example, service providers offering 118 alerting or notification services (e.g., for packages or health 119 alerts) may register their phone numbers, after suitable vetting, in 120 shared databases. Government agencies could publish electronic 121 directories of official telephone numbers, drawing on the historical 122 precedent of the "blue pages" found in printed phone directories. 123 Government regulators for financial services, health care providers 124 and charitable organizations could provide sources of telephone 125 numbers and service types belonging to such organizations. Finally, 126 crowd-sourcing might also be used to populate databases of call 127 types. In the United States, industry organizations have proposed 128 variations of such caller databases to prevent accidental blocking of 129 calls based on their statistics such as frequency or duration alone. 131 Providers may also find the SIP Priority header ([RFC3261], 132 Section 20.26) field useful in helping called parties decide how to 133 respond to an incoming call. 135 2. Normative Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119][RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 3. Overview of Operation 145 This document describes a new set of optional parameters and usage 146 for the SIP [RFC3261] Call-Info header field, with a purpose "info", 147 for labeling the nature of the call. The header field may be 148 inserted by the call originator, an intermediate proxy or B2BUA or 149 the terminating carrier, based on assertions by the caller, number- 150 indexed databases, call analytics or other sources of information. 151 The SIP provider serving the called party MUST remove any parameters 152 enumerated in this specification that it does not trust. 154 To ensure that an untrusted originating caller does not mislead the 155 called party, a new feature capability indicator [RFC6809], sip.call- 156 info.spam, in the REGISTER response signals whether the terminating 157 carrier supports the feature described in this document and thus will 158 remove any untrusted 'confidence', 'origin', 'source' and 'type' 159 Call-Info header field information parameters. It is possible for 160 the terminating carrier to support this feature by simply removing 161 all parameters defined in the document, without inserting any of its 162 own information, although this is likely to be unusual. A user agent 163 MUST ignore any of the parameters defined in this document unless the 164 feature capability indicator is present in the response to the 165 REGISTER request. An example of the REGISTER response is shown in 166 Section 6.1. 168 SIP proxies or B2BUAs MUST add a new Call-Info "info" header field 169 value, rather than add parameters to an existing value. Thus, one 170 SIP request MAY contain several Call-Info header instances of purpose 171 "info", either as a single header with a comma-separated list of 172 header values or separate headers, or some combination. 174 As defined in [RFC3261], the Call-Info header field contains a URI 175 that can provide additional information about the caller or call. 176 For example, many call filtering services provide a web page with 177 crowd-sourced information about the calling number. If the entity 178 inserting the header field does not have information it wants to link 179 to, it MUST use an empty data URL [RFC2397] as a placeholder, as in 180 "data:,". (The Call-Info header field syntax makes the URI itself 181 mandatory.) An example is shown in Section 6.2. 183 4. Parameters 185 All of the parameters listed below are optional and may appear in any 186 combination and order. Their ABNF is defined in Section 7. All 187 except the 'type' parameter are optional. 189 confidence The 'confidence' parameter carries an estimated 190 probability that the call is of the nature indicated in the 'type' 191 parameter, expressed as a whole-number percentage between 0 and 192 100, inclusive, with larger numbers indicating higher probability. 193 The computation of the estimate is beyond the scope of this 194 specification. If a 'type' is not specified, this parameter 195 estimates the likelihood that the call is unwanted spam by the 196 called party. If the confidence level is not specified, the 197 sender considers the information reliable enough to act on, 198 according to its local decision thresholds. 200 origin The origin parameter provides free-text information, as a 201 quoted-text (UTF8-encoded) string, about the source of the 'type' 202 or 'confidence' parameter and is meant to be used for debugging, 203 rather than for display to the end user. For example, it may 204 indicate the name of an external information source, such as a 205 list of known emergency alerters or a government agency. 207 source The source parameter identifies the entity, by host name, 208 domain or IP address, that inserted the 'confidence', 'origin' and 209 'type' parameters. It uses the "host" ABNF syntax. 211 type The type parameter indicates the type of the call or caller. 212 It is drawn from an extensible set of values, with the initial set 213 listed below. Gateways to analog phone systems MAY include the 214 label in caller name (CNAM) information delivered to user 215 equipement. Automated call classification systems MAY use this 216 information as one factor in deciding how to handle the call. 217 Calls SHOULD be labeled with types that may make it more likely 218 that the caller will answer (e.g., for alert and health-related 219 calls) if the entity inserting the information is confident that 220 the calling party number is valid, e.g., because the request has 221 been signed [RFC8224]. 223 5. Call Types 225 The following initial set of types are defined. The call types are 226 generally based on the caller's telephone number or possibly an 227 assertion by a trusted caller, as the content cannot be not known. 228 Each call is tagged with at most one type label, i.e., the labels are 229 meant to be mutually exclusive. The definitions are meant to be 230 informal and reflect the common understanding of subscribers who are 231 not lawyers. By their very nature, this classification may sometimes 232 be erroneous, e.g., if a number has been re-assigned to another 233 entity or if crowd-sourced information is wrong, and thus should be 234 treated as a hint or estimate. Each entity inserting type 235 information will need to define its own policy as to the level of 236 certainty it requires before it inserts type information. 238 Other strings may be used; there does not appear to be a need for 239 defining vendor-defined strings as the likelihood of confusion 240 between a service-provider-specific usage and a later extension to 241 the list appears low. Additional labels are registered with IANA. 243 business Calls placed by businesses, i.e., an entity or enterprise 244 entered into for profit. This type is used if no other, more 245 precise, category fits. 247 debt-collection Calls related to collecting of debt owed or alleged 248 to be owed by the called party. 250 emergency-alert Calls that provide the recipient warnings and alerts 251 regarding a pending or on-going emergency. (This call type is 252 unrelated to emergency calls placed by individuals using emergency 253 numbers such as 9-1-1 or 1-1-2.) 255 fraud The call is considered to be fraudulent. 257 government A call placed by a government entity, if no more specific 258 label such as "health" or "debt-collection" is known or applies. 260 health Informational calls by health plans, health care 261 clearinghouses or health care provider, where health care means 262 care, services, or supplies related to the health of an 263 individual. 265 informational Calls intended to convey information to the called 266 party about a transaction such as package delivery, appointment 267 reminder, or order confirmation. 269 not-for-profit A call placed by a not-for-profit organization, 270 including for soliciting donations or providing information. 272 personal A non-business, person-to-person, call, e.g., from a 273 residential line or personal mobile number. 275 political Calls related to elections or other political purposes. 277 public-service Calls that provide the recipient information 278 regarding public services, e.g., school closings. 280 prison Calls from jails, prisons and other correctional facilities. 282 spam A call that is likely unwanted, if not otherwise classified. 284 spoofed The calling number for this call has been spoofed. (For 285 example, the call has failed STIR validation [RFC8224] within the 286 SIP service provider network or the telephone number is not a 287 valid number or is known not to have been assigned.) 289 survey A call that solicits the opinions or data of the called 290 party. 292 telemarketing Calls placed in order to induce the purchase of a 293 product or service to the called party. 295 trusted The call is being placed by a trusted entity and falls 296 outside the other categories listed. This may include call backs, 297 e.g., from a conferencing service, or messages from 298 telecommunication carriers and utilities. 300 6. Examples 302 6.1. REGISTER Response 304 The example below shows a partial REGISTER response showing that the 305 registrar and proxy will remove any untrusted Call-Info header 306 elements. 308 SIP/2.0 200 OK 309 ... 310 From: Bob ;tag=a73kszlfl 311 To: Bob ;tag=34095828jh 312 ... 313 Feature-Caps: *; +sip.call-info.spam 315 6.2. INVITE Request 317 INVITE sip:alice@example.com SIP/2.0 318 ... 319 Call-Info: 320 ;source=carrier.example.com 321 ;purpose=info ;confidence=85 ;type=fraud 322 ;origin="FTC fraud list" 324 7. ABNF 325 label-info-params = [ci-confidence] / [ci-source] / [ci-origin] / ci-type 326 ci-confidence = "confidence" EQUAL 1*3DIGIT 327 ci-origin = "origin" EQUAL quoted-string 328 ci-source = "source" EQUAL host 329 ci-type = "type" EQUAL ("business" / "debt-collection" / "emergency-alert" / "fraud" / 330 "government" / "health" / "informational" / "not-for-profit" / 331 "personal" / "political" / "public-service" / "prison" / "spam" / 332 "spoofed" / "survey" / "telemarketing" / "trusted" / 333 iana-token) 335 8. IANA Considerations 337 8.1. SIP Call-Info Header Field Parameters 339 This document defines the 'confidence', 'origin', 'source' and 'type' 340 parameters in the Call-Info header in the "Header Field Parameters 341 and Parameter Values" registry defined by [RFC3968]. 343 +--------------+----------------+-------------------+------------+ 344 | Header Field | Parameter Name | Predefined Values | Reference | 345 +--------------+----------------+-------------------+------------+ 346 | [this RFC] | Call-Info | confidence | No | 347 | Call-Info | origin | No | [this RFC] | 348 | Call-Info | source | No | [this RFC] | 349 | Call-Info | type | Yes | [this RFC] | 350 +--------------+----------------+-------------------+------------+ 352 8.2. SIP Global Feature-Capability Indicator 354 This document defines the feature capability sip.call-info.spam in 355 the "SIP Feature-Capability Indicator Registration Tree" registry 356 defined in [RFC6809]. 358 Name sip.call-info.spam 360 Description This feature-capability indicator when used in a 361 REGISTER response indicates that the server will add, inspect, 362 alter and possibly remove the Call-Info header field parameters 363 defined in the reference. 365 Reference [this RFC] 367 8.3. SIP Call-Info Type Parameter 369 This specification establishes the "Call-Info Type" sub-registry 370 under http://www.iana.org/assignments/sip-parameters. Call-Info 371 "type" parameters are used in the "type" parameter in the SIP Call- 372 Info header field. The initial values are listed in Section 5. 374 Additional values are allocated by expert review [RFC5226]; only the 375 token value, using the ABNF iana-token, and a brief description, 376 typically no more than a few sentences, is required. The ABNF for 377 iana-token is defined in [RFC3261]. A specification is not required. 379 9. Security Considerations 381 The security considerations in [RFC3261] (Section 20.9) apply. A 382 user agent MUST ignore the parameters defined in this document unless 383 the SIP REGISTER response contained the sip.call-info.spam feature 384 capability. B2BUAs or proxies that maintain user registrations MUST 385 remove any parameters defined in this document that were provided by 386 untrusted third parties. 388 The UAS SHOULD only consider Call-Info header field information that 389 originates from a registrar that is part of the same trust domain 390 [RFC3324]. 392 The protection offered against rogue SIP entities by the feature 393 capability relies on protecting the REGISTER response against man-in- 394 the-middle attacks that maliciously add the capability indicator. 395 Thus, a UAS SHOULD NOT trust the information in the "Call-Info" 396 header field unless the SIP session between the entity inserting the 397 header field and the UAS is protected by TLS [RFC8446]. 399 Labeling calls is likely only useful if the caller identity can be 400 trusted, e.g., by having the call signaling requests signed 401 [RFC8224], as otherwise spoofed calls would likely be mislabeled and 402 thus increase the likelihood that the called party is mislead, 403 answers unwanted calls or is defrauded. Thus, this information MUST 404 only be added calls with an attestation level of "Full Attestation" 405 [RFC8588] or for calls where the SIP entity inserting the header 406 knows to have correct calling number information, e.g., because the 407 call originated within the same PBX or the same carrier and the 408 operating entity ensures that caller ID spoofing is highly unlikely 409 within their realm of responsibility. 411 10. Acknowledgements 413 Jim Calme and other members of the Robocall Strikeforce helped draft 414 the initial list of call types. Tolga Asveren, Ben Campbell, Keith 415 Drage, Christer Holmberg, Paul Kyzivat and Dale Worley provided 416 helpful comments on the document. 418 11. References 420 11.1. Normative References 422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 423 Requirement Levels", BCP 14, RFC 2119, 424 DOI 10.17487/RFC2119, March 1997, 425 . 427 [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, 428 DOI 10.17487/RFC2397, August 1998, 429 . 431 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 432 A., Peterson, J., Sparks, R., Handley, M., and E. 433 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 434 DOI 10.17487/RFC3261, June 2002, 435 . 437 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 438 Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002, 439 . 441 [RFC3968] Camarillo, G., "The Internet Assigned Number Authority 442 (IANA) Header Field Parameter Registry for the Session 443 Initiation Protocol (SIP)", BCP 98, RFC 3968, 444 DOI 10.17487/RFC3968, December 2004, 445 . 447 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 448 IANA Considerations Section in RFCs", RFC 5226, 449 DOI 10.17487/RFC5226, May 2008, 450 . 452 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 453 Indicate Support of Features and Capabilities in the 454 Session Initiation Protocol (SIP)", RFC 6809, 455 DOI 10.17487/RFC6809, November 2012, 456 . 458 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 459 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 460 May 2017, . 462 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 463 "Authenticated Identity Management in the Session 464 Initiation Protocol (SIP)", RFC 8224, 465 DOI 10.17487/RFC8224, February 2018, 466 . 468 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 469 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 470 . 472 11.2. Informative References 474 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 475 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 476 January 2008, . 478 [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token 479 (PaSSporT) Extension for Signature-based Handling of 480 Asserted information using toKENs (SHAKEN)", RFC 8588, 481 DOI 10.17487/RFC8588, May 2019, 482 . 484 Author's Address 486 Henning Schulzrinne 487 Columbia University 488 450 Computer Science Bldg. 489 New York, NY 10027 490 US 492 Email: hgs@cs.columbia.edu