idnits 2.17.1 draft-ietf-sipcore-rejected-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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (November 25, 2018) is 1979 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) == Missing Reference: 'RFCXXXX' is mentioned on line 641, but not defined -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE E. Burger 3 Internet-Draft Georgetown University 4 Intended status: Standards Track November 25, 2018 5 Expires: May 29, 2019 7 A Session Initiation Protocol (SIP) Response Code for Rejected Calls 8 draft-ietf-sipcore-rejected-01 10 Abstract 12 This document defines the 608 (Rejected) SIP response code. This 13 response code enables calling parties to learn their call was 14 rejected by an intermediary and will not be answered. As a 6xx code, 15 the caller will be aware that future attempts to contact the same UAS 16 will be likely to fail. The present use case driving the need for 17 the 608 response code is when the intermediary is an analytics 18 engine. In this case, the rejection is by a machine or other 19 process. This contrasts with the 607 (Unwanted) SIP response code, 20 which a human at the target UAS indicated the call was not wanted. 21 In some jurisdictions this distinction is important. This document 22 defines the use of the Call-Info header in 608 responses to enable 23 rejected callers to contact entities that blocked their calls in 24 error. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on May 29, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 63 3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 7 64 3.2. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 8 65 3.3. Legacy Interoperation . . . . . . . . . . . . . . . . . . 8 66 3.4. Announcement Requirements . . . . . . . . . . . . . . . . 9 67 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 15 70 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 15 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 75 8.2. Informative References . . . . . . . . . . . . . . . . . 17 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 The IETF has been addressing numerous issues surrounding how to 81 handle unwanted and, depending on the jurisdiction, illegal calls 82 [RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] 83 address cryptographic signing and attestation, respectively, of 84 signaling to ensure the integrity and authenticity of the asserted 85 identity. 87 This document describes a new SIP response code, 608, which allows 88 calling parties to learn an intermediary rejected their call. As 89 described below, we need a distinct indicator to differentiate 90 between a user rejection and an intermediary's rejection of a call. 91 In some jurisdictions, calls, even if unwanted by the user, may not 92 be blocked unless there is an explicit user request. Moreover, users 93 may misidentify the nature of a caller. For example, a legitimate 94 caller may call a user who finds the call to be unwanted. However, 95 instead of marking the call as unwanted, the user may mark the call 96 as illegal. With that information, an analytics engine may determine 97 that all calls from that source should be blocked. However, in some 98 jurisdictions blocking calls from that source for other users may not 99 be legal. Likewise, one can envision jurisdictions that allow an 100 operator to block such calls, but only if there is a remediation 101 mechanism in place to address false positives. 103 Some call blocking services may return responses such as 604 (Does 104 Not Exist Anywhere). This might be a strategy to attempt to get a 105 destination's address removed from a calling database. However, 106 other network elements might interpret this to mean the user truly 107 does not exist and result in the user not being able to receive calls 108 from anyone, even if wanted. As well, in many jurisdictions, 109 providing false signaling is illegal. 111 The 608 response code addresses this need of remediating falsely 112 blocked calls. Specifically, this code informs the UAC an 113 intermediary blocked the call and, to satisfy jurisdictional 114 requirements for providing a redress mechanism, how to contact the 115 operator of the intermediary. 117 In the call handling ecosystem, users can explicitly reject a call or 118 later mark a call as being unwanted by issuing a 607 SIP response 119 code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the operation 120 of the 607 SIP response code. The UAS indicates the call was 121 unwanted. As RFC8197 explains, not only does the called party desire 122 to reject that call, they may wish to let their proxy know they might 123 consider future calls from that source unwanted by responding to the 124 request with the 607 response. Upon receipt of the 607 response from 125 the UAS, the proxy may send call information to a call analytics 126 engine. For various reasons described in RFC8197, if a network 127 operator receives multiple reports of unwanted calls, that may 128 indicate the entity placing the calls is likely to be a source of 129 unwanted calls for many people. As such, other users of the service 130 provider's service may wish the service provider to automatically 131 reject calls on their behalf based on that and other analytics. 133 Another value of the 607 rejection is presuming the proxy forwards 134 the response code to the UAC, the calling UAC or intervening proxies 135 will also learn the user is not interested in receiving calls from 136 that sender. 138 +-----------+ 139 | Call | 140 | Analytics | 141 | Engine | 142 +-----------+ 143 ^ | (likely not SIP) 144 | v 145 +-----------+ 146 +-----+ 607 | Called | 607 +-----+ 147 | UAC | <--------- | Party | <-------- | UAS | 148 +-----+ | Proxy | +-----+ 149 +-----------+ 151 Figure 1: Unwanted (607) Call Flow 153 For calls rejected with a 607 from a legitimate caller, receiving a 154 607 response code can inform the caller to stop attempting to call 155 the user. Moreover, if the legitimate caller believes the user is 156 rejecting their calls in error, they can use other channels to 157 contact the user. For example, if a pharmacy calls a user to let 158 them know their prescription is available for pickup and the user 159 mistakenly thinks the call is unwanted and issues a 607 response 160 code, the pharmacy, having an existing relationship with the 161 customer, can send the user an email, also noting the customer might 162 consider not rejecting their calls in the future. 164 Moreover, many systems that allow the user to mark the call unwanted 165 (e.g., with the 607 response code) also allow the user to change 166 their mind and unmark such calls. This is relatively easy to 167 implement as the user usually has a direct relationship with the 168 provider of the blocking service. 170 +--------+ +-----------+ 171 | Called | | Call | 172 +-----+ | Party | | Analytics | +-----+ 173 | UAC | | Proxy | | Engine | | UAS | 174 +-----+ +--------+ +-----------+ +-----+ 175 | INVITE | | | 176 | --------------> | INVITE | | 177 | | ------------------------------> | 178 | | | | 179 | | | 607 | 180 | | <------------------------------ | 181 | | | | 182 | | Unwanted call | | 183 | 607 | -----------------> | | 184 | <-------------- | indicator | | 185 | | | | 187 Figure 2: Unwanted (607) Ladder Diagram 189 However, things get more complicated if an intermediary, such as a 190 third-party provider of call management services that classify calls 191 based on the relative likelihood the call is unwanted, misidentifies 192 the call as unwanted. Figure 3 shows this case. Note the UAS 193 typically does not receive an INVITE as the proxy rejects the call on 194 behalf of the user. In this situation, it would be beneficial for 195 the caller to be able to learn who rejected the call, so they might 196 be able to correct the misidentification. 198 In this situation, one might be tempted to have the intermediary use 199 the 607 response code. 607 indicates to the caller the subscriber did 200 not get the call and they do not want the call. However, RFC8197 201 specifies that one of the uses of 607 is to inform analytics engines 202 that a user (human) has rejected a call. The problem here is network 203 elements downstream from the intermediary might interpret the 607 as 204 a user (human) marking the call as unwanted, as opposed to a 205 statistical, machine learning, vulnerable to the base rate fallacy 206 [BaseRate] algorithm rejecting the call. In other words, those 207 downstream entities should not be relying on another entity 208 'deciding' the call is unwanted. By distinguishing between a (human) 209 user rejection and an intermediary's statistical rejection, a 210 downstream network element that sees a 607 response code can weight 211 it as a human rejection in its call analytics. 213 +-----------+ 214 | Call | 215 | Analytics | 216 | Engine | 217 +-----------+ 218 ^ | (likely not SIP) 219 | v 220 +-----------+ 221 +-----+ 608 | Called | +-----+ 222 | UAC | <--------- | Party | | UAS | 223 +-----+ | Proxy | +-----+ 224 +-----------+ 226 Figure 3: Rejected (608) Call Flow 228 It is useful for blocked callers to have a redress mechanism. One 229 can imagine that some jurisdictions will require it. However, we 230 must be mindful that most of the calls that will be blocked will, in 231 fact, be illegal and eligible for blocking. Thus, providing 232 alternate contact information for a user would be counterproductive 233 to protecting that user from illegal communications. This is another 234 reason we do not propose to simply allow alternate contact 235 information in a 607 response message. 237 One might ask why we cannot use the same mechanism an analytics 238 service provider offers their customers that lets them correct a call 239 blocked in error? The reason is whilst there is an existing 240 relationship between the customer (called party) and the analytics 241 service provider, it is unlikely there is a relationship between the 242 caller and the analytics service provider. Moreover, there are 243 numerous call blocking providers in the ecosystem. As such, we need 244 a mechanism for indicating an intermediary rejected a call while 245 providing contact information for the operator of the intermediary 246 that provides call rejection services to the called party, without 247 exposing the target user's contact information. 249 The protocol described in this document uses existing IETF protocol 250 mechanisms for specifying the redress mechanism. Specifically, we 251 use jCard [RFC7095] encoding of the redress address. For integrity 252 protection, we sign the redress address. Conveniently, we use jCard 253 rather than vCard [RFC6350] as we have a standard marshaling 254 mechanism for creating a canonical representation of a JSON [RFC8259] 255 object, such as a jCard, and a standard presentation format for such 256 an object, namely JWS [RFC7515]. The SIP community is familiar with 257 this concept as it is the mechanism used by STIR [RFC8224]. 259 2. Terminology 261 This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", 262 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 263 "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only 264 when, they appear in all capitals, as shown here. 266 3. Protocol Operation 268 For clarity, this section uses the term 'intermediary' as the entity 269 that acts as a SIP User Agent Server (UAS) on behalf of the user in 270 the network, as opposed to the user's UAS (colloquially, but not 271 necessarily, their phone). The intermediary could be a back-to-back 272 user agent (B2BUA) or a SIP Proxy. 274 Figure 4 shows an overview of the call flow for a rejected call. 276 +--------+ +-----------+ 277 | Called | | Call | 278 +-----+ | Party | | Analytics | +-----+ 279 | UAC | | Proxy | | Engine | | UAS | 280 +-----+ +--------+ +-----------+ +-----+ 281 | INVITE | | | 282 | --------------> | Information from | | 283 | | -----------------> | | 284 | | INVITE | | 285 | | Reject | | 286 | 608 | <----------------- | | 287 | <-------------- | call | | 288 | | | | 290 Figure 4: Rejected (608) Ladder Diagram 292 3.1. Intermediary Operation 294 An intermediary MAY issue the 608 response code in a failure response 295 for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP 296 [RFC3261] request to indicate that an intermediary rejected the 297 offered communication as unwanted by the user. An intermediary MAY 298 issue the 608 as the value of the "cause" parameter of a SIP reason- 299 value in a Reason header field [RFC3326]. 301 Unless there are indicators the calling party will use the contents 302 of the Call-Info header for malicious purposes (see Section 6), if an 303 intermediary issues a 608 code, the intermediary MUST include a Call- 304 Info header in the response. 306 If there is a Call-Info header, it MUST have the 'purpose' parameter 307 of 'card'. The value of the Call-Info header MUST refer to a valid 308 JWS [RFC7515] encoding of a jCard [RFC7095] object. As for the 309 signature algorithms allowed and policies surrounding the issuance 310 and publication of public and private keys, one could expect to see 311 policies such as defined by SHAKEN [SHAKEN]. However, the 312 specification for the signature algorithm and policies for the 313 asserted keys are beyond the scope of this document. 315 The jCard referenced in the Call-Info header MUST include at least 316 one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this 317 specification MUST be prepared to receive a full jCard. Call 318 originators (at the UAC) can use the information returned by the 319 jCard to contact the intermediary that rejected the call to appeal 320 the intermediary's blocking of the call attempt. What the 321 intermediary does if the blocked caller contacts the intermediary is 322 outside the scope of this document. 324 Proxies need to be mindful that a downstream intermediary may reject 325 the attempt with a 608 while other paths may still be in progress. 326 In this situation, the requirements stated in Section 16.7 of RFC3261 327 [RFC3261] apply. Specifically, the proxy should cancel pending 328 transactions and must not create any new branches. Note this is not 329 a new requirement but simply pointing out the existing 6xx protocol 330 mechanism in SIP. 332 3.2. UAC Operation 334 A UAC conforming to this specification MUST include the sip.608 335 feature capability tag in the INVITE request. 337 Upon receiving a 608 response, UACs perform normal SIP processing for 338 6xx responses. 340 3.3. Legacy Interoperation 342 If the UAC indicates support for 608 and the intermediary issues a 343 608, life is good as the UAC will receive all the information it 344 needs to remediate an erroneous block by an intermediary. However, 345 what if the UAC does not understand 608? Besides a UAC predating 346 this specification, the could occur for callers from the legacy, non- 347 SIP public switched network connecting to the SIP network via a media 348 gateway. 350 We address this situation by having the first network element that 351 conforms with this specification play an announcement in the media. 352 See Section 3.4 for requirements on the announcement. The simple 353 rule is a network element that inserts the sip.608 feature capability 354 MUST be able to convey at a minimum whom to contact, ideally how to 355 contact, the operator of the intermediary that rejected the call 356 attempt. 358 The degenerate case is the intermediary is the only element that 359 understands the semantics of the 608 response code. Obviously, any 360 SIP device will understand that a 608 response code is a 6xx error. 361 However, there are no other elements in the call path that understand 362 the meaning of the value of the Call-Info header. The intermediary 363 knows this is the case as the INVITE request will not have the 364 sip.608 feature capability. In this case, one can consider the 365 intermediary to be the element 'inserting' a virtual sip.608 feature 366 capability. As such, the intermediary MUST play the announcement, 367 with the caveats described in Section 3.4 and Section 6. 369 Now we take the case where a network element that understands the 608 370 response code receives an INVITE for further processing. A network 371 element conforming with this specification MUST insert the sip.608 372 feature capability, per the behaviors described in Section 4.2 of 373 [RFC6809]. This information will be in the JWS of the jCard 374 referenced by the Call-Info header in the 608 response message. Note 375 this specification does not specify the mechanism for such 376 notification to the UAC (see Section 3.4). 378 Do note that even if a network element plays an announcement 379 describing the contents of the 608 response message, the network 380 element MUST also send the 608 response code message as the final 381 response to the INVITE. 383 One aspect of using a feature capability is only the network elements 384 that will consume (UAC) or play an announcement (media gateway, SBC, 385 or proxy) need understand the sip.608 feature capability. All other 386 (existing) infrastructure can remain without modification, assuming 387 they are conformant to Section 16.6 of [RFC3261], specifically they 388 will pass headers such as "Feature-Capability: sip.608" unmodified. 390 3.4. Announcement Requirements 392 There are a few requirements on the element that will be doing the 393 announcement for legacy interoperation. 395 As noted above, the element that inserts the sip.608 feature 396 capability is responsible for conveying the information referenced by 397 the Call-Info header in the 608 response message. However, this 398 specification does not mandate the modality for conveying that 399 information. 401 Let us take the case where a telecommunications service provider 402 controls the element inserting the sip.608 feature capability. It 403 would be reasonable to expect the service provider would play an 404 actual announcement in the media path towards the UAC (caller). It 405 is important to note the network element should be mindful of the 406 media type requested by the UAC as it formulates the announcement. 407 For example, it would make sense for an INVITE that only indicated 408 audio codecs in the SDP [RFC4566] to result in an audio announcement. 409 However, if the INVITE only indicated a real-time text codec, for 410 example, the network element SHOULD send the information in a text 411 format, not an audio format, unless the network element is unable to 412 render the information in the requested media format. 414 It is also possible for the network element inserting the sip.608 415 feature capability to be under the control of the same entity that 416 controls the UAC. For example, a large call center might have legacy 417 UACs, but have a modern outbound calling proxy that understands the 418 full semantics of the 608 response code. In this case, it is enough 419 for the outbound calling proxy to digest the Call-Info information 420 and handle the information digitally, rather than 'transcoding' the 421 Call-Info information for presentation to the caller. 423 4. Examples 425 These examples are not normative, for clarity do not include all 426 protocol elements, and may have errors. Review the protocol 427 documents for actual syntax and semantics of the protocol elements. 429 Given an INVITE (shamelessly taken from [SHAKEN]): 431 INVITE sip:+12155551213@tel.example1.net SIP/2.0 432 Max-Forwards: 69 433 Contact: 434 To: 435 From: "Alice" ;tag=614bdb40 436 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 437 P-Asserted-Identity: "Alice", 438 439 CSeq: 2 INVITE 440 Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, 441 MESSAGE, OPTIONS 442 Content-Type: application/sdp 443 Date: Tue, 16 Aug 2016 19:23:38 GMT 444 Feature-Caps: sip.608 445 Identity: 446 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I 447 joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC 448 J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI 449 xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 450 IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n 451 Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC 452 A;info=;alg=ES256 453 Content-Length: 153 455 v=0 456 o=- 13103070023943130 1 IN IP4 192.0.2.177 457 c=IN IP4 192.0.2.177 458 t=0 0 459 m=audio 54242 RTP/AVP 0 460 a=sendrecv 462 An intermediary could reply: 464 SIP/2.0 608 Rejected 465 Via: SIP/2.0/UDP 192.0.2.177:60012;branch=z9hG4bK-524287-1 466 From: "Alice" ;tag=614bdb40 467 To: 468 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 469 CSeq: 2 INVITE 470 Call-Info: ;purpose=card 472 A minimal jCard could be: 474 ["vcard", 475 [ 476 ["version", {}, "text", "4.0"], 477 ["fn", {}, "text", "Robocall Adjudication"], 478 ["email", {"type":"work"}, 479 "text", "bitbucket@blocker.example.net"] 480 ] 481 ] 483 In base64: 485 WyJ2Y2FyZCIsCiAgWwogICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJd 486 LAogICAgWyJmbiIsIHt9LCAidGV4dCIsICJSb2JvY2FsbCBBZGp1ZGljYXRpb24i 487 XSwKICAgIFsiZW1haWwiLCB7InR5cGUiOiJ3b3JrIn0sICJ0ZXh0IiwgImJpdGJ1 488 Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICBdCl0K 490 The JWS header of this example jCard could be: 492 { {"alg":"ES256"}, 493 {"typ":"vcard+json"}, 494 {"x5u":"https://certs.example.net/reject_key.cer"} } 496 In base64: 498 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 499 NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 500 fQo= 502 The resulting JWS, presuming the base64 encoding of the ECDSA P-256 503 SHA-256 digital signature using the certificate mentioned above is, 504 the final string after the period in the example below, stored at 505 https://blocker.example.net/complaints.json, the file could thus 506 contain: 508 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 509 NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g 510 fQo=.WyJ2Y2FyZCIsCiAgWwogICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQ 511 uMCJdLAogICAgWyJmbiIsIHt9LCAidGV4dCIsICJSb2JvY2FsbCBBZGp1ZGljYXR 512 pb24iXSwKICAgIFsiZW1haWwiLCB7InR5cGUiOiJ3b3JrIn0sICJ0ZXh0IiwgImJ 513 pdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICBdCl0K.OSaG/DGW8jxfWM 514 Z+cExnmhCPEXxIg+dEiJakRKD/E4KZak8PsEv/5Bh0bz9KMv8d+o6JnT76v9cuk+ 515 d3CxE3HW 517 For an intermediary that provides a Web site for adjudication, the 518 jCard could contain the following. Note the calculation of the JWS 519 is not shown; the URI reference in the Call-Info header would be to 520 the JWS of the signed jCard. 522 ["vcard", 523 [ 524 ["version", {}, "text", "4.0"], 525 ["fn", {}, "text", "Robocall Adjudication"], 526 ["url", {"type":"work"}, 527 "text", "https://blocker.example.net/adjudication-form"] 528 ] 529 ] 531 For an intermediary that provides a telephone number and a postal 532 address, the jCard could contain the following. Note the calculation 533 of the JWS is not shown; the URI reference in the Call-Info header 534 would be to the JWS of the signed jCard. 536 ["vcard", 537 [ 538 ["version", {}, "text", "4.0"], 539 ["fn", {}, "text", "Robocall Adjudication"], 540 ["adr", {"type":"work"}, "text", 541 ["Argument Clinic", 542 "12 Main St","Anytown","AP","000000","Somecountry"] 543 ] 544 ["tel", {"type":"work"}, "uri", "tel:+1-555-555-1212"] 545 ] 546 ] 548 Note that it is up to the UAC to decide which jCard contact modality, 549 if any, it will use. 551 Figure 5 depicts a call flow illustrating legacy interoperability. 552 In this non-normative example, we see a UAC that does not support the 553 full semantics for 608. However, there is an SBC that does support 554 608. Per RFC6809 [RFC6809], the SBC can insert "sip.608" into the 555 Feature-Caps header for the INVITE. When the intermediary, labeled 556 "Called Party Proxy" in the figure, rejects the call, it knows it can 557 simply perform the processing described in this document. Since the 558 intermediary saw the sip.608 feature capability, it knows it does not 559 need to send any media describing whom to contact in the event of an 560 erroneous rejection. 562 +---------+ 563 | Call | 564 |Analytics| 565 | Engine | 566 +---------+ 567 ^ | 568 | v 569 +---------+ 570 | Called | +-----+ +-----+ +---+ +-----+ +---+ 571 | Party | <---|Proxy| <---|Proxy| <---|SBC| <---|Proxy| <---|UAC| 572 | Proxy | +-----+ +-----+ +---+ +-----+ +---+ 573 +---------+ | | 574 | | INVITE | 575 | INVITE |<--------------------| 576 |<-----------------------------------| | 577 | Feature-Caps: sip.608 | | 578 | | | 579 | 608 Rejected | | 580 |----------------------------------->| 183 | 581 | Call-Info: <...> |-------------------->| 582 | [path for Call-Info elided | SDP for media | 583 | for illustration purposes] | | 584 | |=== Announcement ===>| 585 | | | 586 | | 608 | 587 | |-------------------->| 588 | | Call-Info: <...> | 590 Figure 5: Legacy Operation 592 When the SBC receives the 608 response code, it correlates that with 593 the original INVITE from the UAC. The SBC remembers that it inserted 594 the sip.608 feature capability, which means it is responsible for 595 somehow alerting the UAC the call failed and whom to contact. At 596 this point the SBC can play a prompt, either natively or through a 597 mechanism such as NETANN [RFC4240], that sends the relevant 598 information in the appropriate media to the UAC. 600 As an example, the SBC could extract the FN and TEL jCard fields and 601 play something like a special information tone (see Telcordia SR-2275 602 [SR-2275] section 6.21.2.1 or ITU-T E.180 [ITU.E.180.1998] section 603 7), followed by "Your call has been rejected by ...", followed by a 604 text-to-speech translation of the FN text, followed by "You can reach 605 them on", followed by a text-to-speech translation of the telephone 606 number in the TEL field. 608 Note the SBC also still sends the full 608 response code, including 609 the Call-Info header, towards the UAC. 611 5. IANA Considerations 613 5.1. SIP Response Code 615 This document defines a new SIP response code, 608. Please register 616 the response code in the "Response Codes" subregistry of the "Session 617 Initiation Protocol (SIP) Parameters" registry at 618 . 620 Response code: 608 622 Description: Rejected 624 Reference: [RFCXXXX] 626 5.2. SIP Feature-Capability Indicator 628 This document defines the feature capability sip.608 in the "SIP 629 Feature-Capability Indicator Registration Tree" registry defined in 630 [RFC6809]. 632 Name: sip.608 634 Description: This feature capability indicator, when included in a 635 Feature-Caps header field of an INVITE request, indicates that the 636 entity that inserted the sip.608 Feature-Caps value will be 637 responsible for indicating to the caller any information contained in 638 the 608 SIP response code, specifically the value referenced by the 639 Call-Info header. 641 Reference: [RFCXXXX] 643 6. Security Considerations 645 Intermediary operators need to be mindful of whom they are sending 646 the 608 response to. There is a risk that a truly malicious caller 647 is being rejected. This raises two issues. The first is the caller, 648 being alerted their call is being automatically rejected, may change 649 their call behavior to defeat call blocking systems. The second, and 650 more significant risk, is that by providing a contact in the Call- 651 Info field, the intermediary may be giving the malicious caller a 652 vector for attack. In other words, the intermediary will be 653 publishing an address that a malicious actor may use to launch an 654 attack on the intermediary. Because of this, intermediary operators 655 may wish to configure their response to only include a Call-Info 656 field for INVITE or other initiating methods that are signed and pass 657 validation by STIR [RFC8224]. 659 Another risk is for an attacker to purposely not include the sip.608 660 feature capability in a flood of INVITE requests, direct those 661 requests to proxies known to insert the sip.608 feature, and direct 662 the SDP to a victim device. Because the mechanism described here can 663 result in an audio file being sent to the target of the Contact 664 header, an attacker could use the mechanism described by this 665 document as an amplification attack, given a SIP INVITE can be under 666 1 kilobyte and an audio file can be hundreds of kilobytes. One 667 remediation for this is for devices that insert a sip.608 feature 668 capability only transmit media to what is highly likely to be the 669 actual source of the call attempt. A method for this is to only play 670 media in response to an INVITE that is signed and passed validation 671 by STIR [RFC8224]. 673 Yet another risk is a malicious entity or the intermediary itself can 674 generate a malicious 608 response with a jCard referring to a 675 malicious agent. For example, the recipient of a 608 may receive a 676 TEL URI in the vCard. When the recipient calls that address, the 677 malicious agent could ask for personally identifying information. 678 However, instead of using that information to verify the recipient's 679 identity, they are pharming the information for nefarious ends. As 680 such, we strongly recommend the recipient validates to whom they are 681 communicating with if asking to adjudicate an erroneously rejected 682 call attempt. Since we may also be concerned about intermediate 683 nodes modifying contact information, we can address both of these 684 issues with a single solution. The remediation is to require the 685 intermediary to sign the jCard. Signing the jCard provides integrity 686 protection. In addition, one can imagine mechanisms such as used by 687 SHAKEN [SHAKEN] to use signing certificate issuance as a mechanism 688 for traceback to the entity issuing the jCard, for example tying the 689 identity of the subject of the certificate to the To field of the 690 initial SIP request, as if the intermediary was vouching for the From 691 field of a SIP request with that identity. 693 7. Acknowledgements 695 This document liberally lifts from [RFC8197] in its text and 696 structure. However, the mechanism and purpose of 608 is quite 697 different than 607. Any errors are the current editor's and not the 698 editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ 699 Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on 700 improving the draft. Tolga's suggestion to provide a mechanism for 701 legacy interoperability served to expand the draft by 50%. In 702 addition, Tolga came up with the jCard attack. 704 8. References 706 8.1. Normative References 708 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 709 Requirement Levels", BCP 14, RFC 2119, 710 DOI 10.17487/RFC2119, March 1997, 711 . 713 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 714 A., Peterson, J., Sparks, R., Handley, M., and E. 715 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 716 DOI 10.17487/RFC3261, June 2002, 717 . 719 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 720 Header Field for the Session Initiation Protocol (SIP)", 721 RFC 3326, DOI 10.17487/RFC3326, December 2002, 722 . 724 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 725 Indicate Support of Features and Capabilities in the 726 Session Initiation Protocol (SIP)", RFC 6809, 727 DOI 10.17487/RFC6809, November 2012, 728 . 730 [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, 731 DOI 10.17487/RFC7095, January 2014, 732 . 734 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 735 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 736 2015, . 738 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 739 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 740 May 2017, . 742 8.2. Informative References 744 [BaseRate] 745 Bar-Hillel, M., "The Base-Rate Fallacy in Probability 746 Judgements", 4 1977, 747 . 749 [ITU.E.180.1998] 750 International Telecommunications Union, "Technical 751 characteristics of tones for the telephone service", 752 ITU Recommendation E.180/Q.35, March 1998. 754 [RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic 755 Network Media Services with SIP", RFC 4240, 756 DOI 10.17487/RFC4240, December 2005, 757 . 759 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 760 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 761 July 2006, . 763 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 764 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 765 January 2008, . 767 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 768 DOI 10.17487/RFC6350, August 2011, 769 . 771 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 772 Telephone Identity Problem Statement and Requirements", 773 RFC 7340, DOI 10.17487/RFC7340, September 2014, 774 . 776 [RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", 777 RFC 8197, DOI 10.17487/RFC8197, July 2017, 778 . 780 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 781 "Authenticated Identity Management in the Session 782 Initiation Protocol (SIP)", RFC 8224, 783 DOI 10.17487/RFC8224, February 2018, 784 . 786 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 787 Interchange Format", STD 90, RFC 8259, 788 DOI 10.17487/RFC8259, December 2017, 789 . 791 [SHAKEN] Alliance for Telecommunications Industry Solutions (ATIS) 792 and the SIP Forum, "Signature-based Handling of Asserted 793 information using toKENs (SHAKEN)", ATIS 1000074, 1 2017, 794 . 798 [SR-2275] Telcordia, "Bellcore Notes on the Networks", Telcordia SR- 799 2275, October 2000. 801 Author's Address 803 Eric W. Burger 804 Georgetown University 805 37th & O St, NW 806 Washington, DC 20057 807 USA 809 Email: eburger@standardstrack.com