idnits 2.17.1 draft-ietf-sipcore-rejected-00.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 (August 21, 2018) is 2072 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 556, 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 August 21, 2018 5 Expires: February 22, 2019 7 A Session Initiation Protocol (SIP) Response Code for Rejected Calls 8 draft-ietf-sipcore-rejected-00 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 and may have 22 additional requirements beyond the 607 response code. Specifically, 23 this document defines the use of the Call-Info header in 608 24 responses to enable rejected callers to contact entities that blocked 25 their calls in error. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 22, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 The IETF has been addressing numerous issues surrounding how to 62 handle unwanted and, depending on the jurisdiction, illegal calls 63 [RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] 64 address cryptographic signing and attestation, respectively, of 65 signaling to ensure the integrity and authenticity of the asserted 66 identity. 68 This document describes a new SIP response code, 608, which allows 69 calling parties to learn an intermediary rejected their call. As 70 described below, we need a distinct indicator to differentiate 71 between a user rejection and an intermediary's rejection of a call. 72 In some jurisdictions, calls, even if unwanted by the user, may not 73 be blocked unless there is an explicit user request. Moreover, users 74 may misidentify the nature of a caller. For example, a legitimate 75 caller may call a user who finds the call to be unwanted. However, 76 instead of marking the call as unwanted, the user may mark the call 77 as illegal. With that information, an analytics engine may determine 78 that all calls from that source should be blocked. However, in some 79 jurisdictions blocking calls from that source for other users may not 80 be legal. Likewise, one can envision jurisdictions that allow an 81 operator to block such calls, but only if there is a remediation 82 mechanism in place to address false positives. 84 Some call blocking services may return responses such as 604 (Does 85 Not Exist Anywhere). This might be a strategy to attempt to get a 86 destination's address removed from a calling database. However, 87 other network elements might interpret this to mean the user truly 88 does not exist and result in the user not being able to receive calls 89 from anyone, even if wanted. As well, in many jurisdictions, 90 providing false signaling is illegal. 92 The 608 response code addresses this need of remediating falsely 93 blocked calls. Specifically, this code informs the UAC an 94 intermediary blocked the call and, to satisfy some jurisdictional 95 requirements for providing a redress mechanism, how to contact the 96 operator of the intermediary. 98 In the call handling ecosystem, users can explicitly reject a call or 99 later mark a call as being unwanted by issuing a 607 SIP response 100 code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the operation 101 of the 607 SIP response code. The UAS indicates the call was 102 unwanted. As RFC8197 explains, not only does the called party desire 103 to reject that call, they may wish to let their proxy know they might 104 consider future calls from that source unwanted. Upon receipt of the 105 607 response from the UAS, the proxy may send call information to a 106 call analytics engine. For various reasons described in RFC8197, if 107 a network operator receives multiple reports of unwanted calls, that 108 may indicate the entity placing the calls is likely to be a source of 109 unwanted calls for many people. As such, other users of the service 110 provider's service may wish the service provider to automatically 111 reject calls on their behalf based on that and other analytics. 113 Another value of the 607 rejection is presuming the proxy forwards 114 the response code to the UAC, the calling UAC or intervening proxies 115 know the user is not interested in receiving calls from that sender. 117 +-----------+ 118 | Call | 119 | Analytics | 120 | Engine | 121 +-----------+ 122 ^ | (likely not SIP) 123 | v 124 +-----------+ 125 +-----+ 607 | Called | 607 +-----+ 126 | UAC | <--------- | Party | <-------- | UAS | 127 +-----+ | Proxy | +-----+ 128 +-----------+ 130 Figure 1: Unwanted (607) Call Flow 132 For calls rejected with a 607 from a legitimate caller, receiving a 133 607 response code can inform the caller to stop attempting to call 134 the user. Moreover, if the legitimate caller believes the user is 135 rejecting their calls in error, they can use other channels to 136 contact the user. For example, if a pharmacy calls a user to let 137 them know their prescription is available for pickup and the user 138 mistakenly thinks the call is unwanted and issues a 607 response 139 code, the pharmacy, having an existing relationship with the 140 customer, can send the user an email, also noting they might consider 141 not rejecting their calls in the future. 143 Moreover, many systems that allow the user to mark the call unwanted 144 (e.g., with the 607 response code) also allow the user to change 145 their mind and unmark such calls. This is relatively easy to 146 implement as the user usually has a direct relationship with the 147 provider of the blocking service. 149 +--------+ +-----------+ 150 | Called | | Call | 151 +-----+ | Party | | Analytics | +-----+ 152 | UAC | | Proxy | | Engine | | UAS | 153 +-----+ +--------+ +-----------+ +-----+ 154 | INVITE | | | 155 | --------------> | INVITE | | 156 | | ------------------------------> | 157 | | | | 158 | | | 607 | 159 | | <------------------------------ | 160 | | | | 161 | | Unwanted call | | 162 | 607 | -----------------> | | 163 | <-------------- | indicator | | 164 | | | | 166 Figure 2: Unwanted (607) Ladder Diagram 168 However, things get more complicated if an intermediary, such as a 169 third-party provider of call management services that classify calls 170 based on the relative likelihood the call is unwanted, misidentifies 171 the call as unwanted. Figure 3 shows this case. Note the UAS 172 typically does not receive an INVITE as the proxy rejects the call on 173 behalf of the user. In this situation, it would be beneficial for 174 the caller to be able to learn who rejected the call, so they might 175 be able to correct the misidentification. 177 In this situation, one might be tempted to have the intermediary use 178 the 607 response code. 607 indicates to the caller the subscriber 179 did not get the call and they do not want the call. However, RFC8197 180 specifies that one of the uses of 607 is to inform analytics engines 181 that a user (human) has rejected a call. The problem here is network 182 elements downstream from the intermediary might interpret the 607 as 183 a user (human) marking the call as unwanted, as opposed to a 184 statistical, machine learning, vulnerable to the base rate fallacy 185 [BaseRate] algorithm rejecting the call. In other words, those 186 downstream entities should not be relying on another entity 187 'deciding' the call is unwanted. By distinguishing between a (human) 188 user rejection and an intermediary's statistical rejection, a 189 downstream network element that sees a 607 response code can weight 190 it as a human rejection in its call analytics. 192 +-----------+ 193 | Call | 194 | Analytics | 195 | Engine | 196 +-----------+ 197 ^ | (likely not SIP) 198 | v 199 +-----------+ 200 +-----+ 608 | Called | +-----+ 201 | UAC | <--------- | Party | | UAS | 202 +-----+ | Proxy | +-----+ 203 +-----------+ 205 Figure 3: Rejected (608) Call Flow 207 It is useful for blocked callers to have a redress mechanism. One 208 can imagine that some jurisdictions will require it. However, we 209 must be mindful that most of the calls that will be blocked will, in 210 fact, be illegal and eligible for blocking. Thus, providing 211 alternate contact information for a user would be counterproductive 212 to protecting that user from illegal communications. This is another 213 reason we do not propose to simply allow alternate contact 214 information in a 607 response message. 216 One might ask why we cannot use the same mechanism an analytics 217 service provider offers their customers that lets them correct a call 218 blocked in error? The reason is whilst there is an existing 219 relationship between the customer (called party) and the analytics 220 service provider, it is unlikely there is a relationship between the 221 caller and the analytics service provider. Moreover, there are 222 numerous call blocking providers in the ecosystem. As such, we need 223 a mechanism for indicating an intermediary rejected a call while 224 providing contact information for the operator of the intermediary 225 that provides call rejection services to the called party, without 226 exposing the target user's contact information. 228 2. Terminology 230 This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", 231 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 232 "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only 233 when, they appear in all capitals, as shown here. 235 3. Protocol Operation 237 For clarity, this section uses the term 'intermediary' as the entity 238 that acts as a SIP User Agent Server (UAS) on behalf of the user in 239 the network, as opposed to the user's UAS (colloquially, but not 240 necessarily, their phone). The intermediary could be a back-to-back 241 user agent (B2BUA) or a SIP Proxy. 243 Figure 4 shows an overview of the call flow for a rejected call. 245 +--------+ +-----------+ 246 | Called | | Call | 247 +-----+ | Party | | Analytics | +-----+ 248 | UAC | | Proxy | | Engine | | UAS | 249 +-----+ +--------+ +-----------+ +-----+ 250 | INVITE | | | 251 | --------------> | Information from | | 252 | | -----------------> | | 253 | | INVITE | | 254 | | Reject | | 255 | 608 | <----------------- | | 256 | <-------------- | call | | 257 | | | | 259 Figure 4: Rejected (608) Ladder Diagram 261 3.1. Intermediary Operation 263 An intermediary MAY issue the 608 response code in a failure response 264 for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP 265 [RFC3261] request to indicate that an intermediary rejected the 266 offered communication as unwanted by the user. An intermediary MAY 267 issue the 608 as the value of the "cause" parameter of a SIP reason- 268 value in a Reason header field [RFC3326]. 270 Unless there are indicators the calling party will use the contents 271 of the Call-Info header for malicious purposes (see Section 6), if an 272 intermediary issues a 608 code, the intermediary MUST include a Call- 273 Info header in the response. 275 If there is a Call-Info header, it MUST have the 'purpose' parameter 276 of 'card'. The value of the Call-Info header MUST refer to a valid 277 vCard [RFC6350] object. 279 The vCard referenced in the Call-Info header MUST include at least 280 one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this 281 specification MUST be prepared to receive a full vCard. Call 282 originators (at the UAC) can use the information returned by the 283 vCard to contact the intermediary that rejected the call to appeal 284 the intermediary's blocking of the call attempt. What the 285 intermediary does if the blocked caller contacts the intermediary is 286 outside the scope of this document. 288 Proxies need to be mindful that a downstream intermediary may reject 289 the attempt with a 608 while other paths may still be in progress. 290 In this situation, the requirements stated in Section 16.7 of RFC3261 291 [RFC3261] apply. Specifically, the proxy should cancel pending 292 transactions and must not create any new branches. Note this is not 293 a new requirement but simply pointing out the existing 6xx protocol 294 mechanism in SIP. 296 3.2. UAC Operation 298 A UAC conforming to this specification MUST include the sip.608 299 feature capability tag in the INVITE request. 301 Upon receiving a 608 response, UACs perform normal SIP processing for 302 6xx responses. 304 3.3. Legacy Interoperation 306 If the UAC indicates support for 608 and the intermediary issues a 307 608, life is good as the UAC will receive all the information it 308 needs to remediate an erroneous block by an intermediary. However, 309 what if the UAC does not understand 608? Besides a UAC predating 310 this specification, the could occur for callers from the legacy, non- 311 SIP public switched network connecting to the SIP network via a media 312 gateway. 314 We address this situation by having the first network element that 315 conforms with this specification play an announcement in the media. 316 See Section 3.4 for requirements on the announcement. The simple 317 rule is a network element that inserts the sip.608 feature capability 318 MUST be able to convey at a minimum whom to contact, ideally how to 319 contact, the operator of the intermediary that rejected the call 320 attempt. 322 The degenerate case is the intermediary is the only element that 323 understands the semantics of the 608 response code. Obviously, any 324 SIP device will understand that a 608 response code is a 6xx error. 325 However, there are no other elements in the call path that understand 326 the meaning of the value of the Call-Info header. The intermediary 327 knows this is the case as the INVITE request will not have the 328 sip.608 feature capability. In this case, one can consider the 329 intermediary to be the element 'inserting' a virtual sip.608 feature 330 capability. As such, the intermediary MUST play the announcement, 331 with the caveats described in Section 3.4 and Section 6. 333 Now we take the case where a network element that understands the 608 334 response code receives an INVITE for further processing. A network 335 element conforming with this specification MUST insert the sip.608 336 feature capability, per the behaviors described in Section 4.2 of 337 [RFC6809]. This information will be in the vCard referenced by the 338 Call-Info header in the 608 response message. Note this 339 specification does not specify the mechanism for such notification to 340 the UAC (see Section 3.4). 342 Do note that even if a network element plays an announcement 343 describing the contents of the 608 response message, the network 344 element MUST also send the 608 response code message as the final 345 response to the INVITE. 347 One aspect of using a feature capability is only the network elements 348 that will consume (UAC) or play an announcement (media gateway, SBC, 349 or proxy) need understand the sip.608 feature capability. All other 350 (existing) infrastructure can remain without modification, assuming 351 they are conformant to Section 16.6 of [RFC3261], specifically they 352 will pass headers such as "Feature-Capability: sip.608" unmodified. 354 3.4. Announcement Requirements 356 There are a few requirements on the element that will be doing the 357 announcement for legacy interoperation. 359 As noted above, the element that inserts the sip.608 feature 360 capability is responsible for conveying the information referenced by 361 the Call-Info header in the 608 response message. However, this 362 specification does not mandate the modality for conveying that 363 information. 365 Let us take the case where a telecommunications service provider 366 controls the element inserting the sip.608 feature capability. It 367 would be reasonable to expect the service provider would play an 368 actual announcement in the media path towards the UAC (caller). It 369 is important to note the network element should be mindful of the 370 media type requested by the UAC as it formulates the announcement. 371 For example, it would make sense for an INVITE that only indicated 372 audio codecs in the SDP [RFC4566] to result in an audio announcement. 373 However, if the INVITE only indicated a real-time text codec, for 374 example, the network element SHOULD send the information in a text 375 format, not an audio format, unless the network element is unable to 376 render the information in the requested media format. 378 It is also possible for the network element inserting the sip.608 379 feature capability to be under the control of the same entity that 380 controls the UAC. For example, a large call center might have legacy 381 UACs, but have a modern outbound calling proxy that understands the 382 full semantics of the 608 response code. In this case, it is enough 383 for the outbound calling proxy to digest the Call-Info information 384 and handle the information digitally, rather than 'transcoding' the 385 Call-Info information for presentation to the caller. 387 4. Examples 389 These examples are not normative, for clarity do not include all 390 protocol elements, and may have errors. Review the protocol 391 documents for actual syntax and semantics of the protocol elements. 393 Given an INVITE (shamelessly taken from [SHAKEN]): 395 INVITE sip:+12155551213@tel.example1.net SIP/2.0 396 Max-Forwards: 69 397 Contact: 398 To: 399 From: "Alice" ;tag=614bdb40 400 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 401 P-Asserted-Identity: "Alice", 402 403 CSeq: 2 INVITE 404 Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, 405 MESSAGE, OPTIONS 406 Content-Type: application/sdp 407 Date: Tue, 16 Aug 2016 19:23:38 GMT 408 Feature-Caps: sip.608 409 Identity: 410 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I 411 joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC 412 J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI 413 xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 414 IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n 415 Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC 416 A;info=;alg=ES256 417 Content-Length: 153 419 v=0 420 o=- 13103070023943130 1 IN IP4 192.0.2.177 421 c=IN IP4 192.0.2.177 422 t=0 0 423 m=audio 54242 RTP/AVP 0 424 a=sendrecv 425 An intermediary could reply: 427 SIP/2.0 608 Rejected 428 Via: SIP/2.0/UDP 192.0.2.177:60012;branch=z9hG4bK-524287-1 429 From: "Alice" ;tag=614bdb40 430 To: 431 Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI 432 CSeq: 2 INVITE 433 Call-Info: ;purpose=card 435 A minimal vCard, in this example at https://blocker.example.net/ 436 complaints.vcf, could contain: 438 BEGIN:VCARD 439 VERSION:4.0 440 FN:Robocall Adjudication 441 EMAIL;TYPE=work:bitbucket@blocker.example.net 442 END:VCARD 444 For an intermediary that provides a Web site for adjudication, the 445 vCard could contain: 447 BEGIN:VCARD 448 VERSION:4.0 449 FN:Robocall Adjudication 450 URL;TYPE=work:https://blocker.example.net/adjudication-form 451 END:VCARD 453 For an intermediary that provides a telephone number and a postal 454 address, the vCard could contain: 456 BEGIN:VCARD 457 VERSION:4.0 458 FN:Robocall Adjudication 459 ADR;TYPE=work;Argument Clinic;12 Main St;Anytown;AP;000000;Somewhere 460 TEL;VALUE=uri;TYPE=work:tel:+1-555-555-1212 461 END:VCARD 463 Note that it is up to the UAC to decide which vCard contact modality, 464 if any, it will use. 466 Figure 5 depicts a call flow illustrating legacy interoperability. 467 In this non-normative example, we see a UAC that does not support the 468 full semantics for 608. However, there is an SBC that does support 469 608. Per RFC6809 [RFC6809], the SBC can insert "sip.608" into the 470 Feature-Caps header for the INVITE. When the intermediary, labeled 471 "Called Party Proxy" in the figure, rejects the call, it knows it can 472 simply perform the processing described in this document. Since the 473 intermediary saw the sip.608 feature capability, it knows it does not 474 need to send any media describing whom to contact in the event of an 475 erroneous rejection. 477 +---------+ 478 | Call | 479 |Analytics| 480 | Engine | 481 +---------+ 482 ^ | 483 | v 484 +---------+ 485 | Called | +-----+ +-----+ +---+ +-----+ +---+ 486 | Party | <---|Proxy| <---|Proxy| <---|SBC| <---|Proxy| <---|UAC| 487 | Proxy | +-----+ +-----+ +---+ +-----+ +---+ 488 +---------+ | | 489 | | INVITE | 490 | INVITE |<--------------------| 491 |<-----------------------------------| | 492 | Feature-Caps: sip.608 | | 493 | | | 494 | 608 Rejected | | 495 |----------------------------------->| 183 | 496 | Call-Info: <...> |-------------------->| 497 | [path for Call-Info elided | SDP for media | 498 | for illustration purposes] | | 499 | |=== Announcement ===>| 500 | | | 501 | | 608 | 502 | |-------------------->| 503 | | Call-Info: <...> | 505 Figure 5: Legacy Operation 507 When the SBC receives the 608 response code, it correlates that with 508 the original INVITE from the UAC. The SBC remembers that it inserted 509 the sip.608 feature capability, which means it is responsible for 510 somehow alerting the UAC the call failed and whom to contact. At 511 this point the SBC can play a prompt, either natively or through a 512 mechanism such as NETANN [RFC4240], that sends the relevant 513 information in the appropriate media to the UAC. 515 As an example, the SBC could extract the FN and TEL vCard fields and 516 play something like a special information tone (see Telcordia SR-2275 517 [SR-2275] section 6.21.2.1 or ITU-T E.180 [ITU.E.180.1998] section 518 7), followed by "Your call has been rejected by ...", followed by a 519 text-to-speech translation of the FN text, followed by "You can reach 520 them on", followed by a text-to-speech translation of the telephone 521 number in the TEL field. 523 Note the SBC also still sends the full 608 response code, including 524 the Call-Info header, towards the UAC. 526 5. IANA Considerations 528 5.1. SIP Response Code 530 This document defines a new SIP response code, 608. Please register 531 the response code in the "Response Codes" subregistry of the "Session 532 Initiation Protocol (SIP) Parameters" registry at 533 . 535 Response code: 608 537 Description: Rejected 539 Reference: [RFCXXXX] 541 5.2. SIP Feature-Capability Indicator 543 This document defines the feature capability sip.608 in the "SIP 544 Feature-Capability Indicator Registration Tree" registry defined in 545 [RFC6809]. 547 Name: sip.608 549 Description: This feature capability indicator, when included in a 550 Feature-Caps header field of an INVITE request, indicates that the 551 entity that inserted the sip.608 Feature-Caps value will be 552 responsible for indicating to the caller any information contained in 553 the 608 SIP response code, specifically the value referenced by the 554 Call-Info header. 556 Reference: [RFCXXXX] 558 6. Security Considerations 560 Intermediary operators need to be mindful of whom they are sending 561 the 608 response to. There is a risk that a truly malicious caller 562 is being rejected. This raises two issues. The first is the caller, 563 being alerted their call is being automatically rejected, may change 564 their call behavior to defeat call blocking systems. The second, and 565 more significant risk, is that by providing a contact modality in the 566 Call-Info field, the intermediary may be giving the malicious caller 567 a vector for attack. In other words, the intermediary will be 568 publishing an address that a malicious actor may use to launch an 569 attack on the intermediary. Because of this, intermediary operators 570 may wish to configure their response to only include a Call-Info 571 field for INVITE or other initiating methods that are signed and pass 572 validation by STIR [RFC8224]. 574 Another risk is for an attacker to purposely not include the sip.608 575 feature capability in a flood of INVITE requests, with the first Via 576 header to a victim device. Worse, the attacker can format an SDP 577 [RFC4566] body with the IP address of a victim device in a c-line. 578 Because the mechanism described here can result in an audio file 579 being sent to the target of the Contact header, an attacker could use 580 the mechanism described by this document as an amplification attack, 581 given a SIP INVITE can be under 1 kilobyte and an audio file can be 582 hundreds of kilobytes. One remediation for this is for intermediate 583 devices that insert a sip.608 feature capability only transmit media 584 back to what is highly likely to be the actual source of the call 585 attempt. A method for this is to only play media in response to an 586 INVITE that is signed and passed validation by STIR [RFC8224]. 588 Yet another risk is a malicious entity can generate a 608 response 589 with a vCard referring to a malicious agent. For example, the 590 recipient of a 608 may receive a TEL URI in the vCard. When the 591 recipient calls that address, the malicious agent could ask for 592 personally identifying information. However, instead of using that 593 information to verify the recipient's identity, they are pharming the 594 information for nefarious ends. As such, we strongly recommend the 595 recipient validates to whom they are communicating with if asking to 596 adjudicate an erroneously rejected call attempt. Unlike the INVITE 597 case where we can suggest only responding to STIR-validated requests, 598 there is no integrity protection of vCard data in such a way one can 599 trace back the provenance of the data. That is an opportunity for 600 future work. 602 7. Acknowledgements 604 This document liberally lifts from [RFC8197] in its text and 605 structure. However, the mechanism and purpose of 608 is quite 606 different than 607. Any errors are the current editor's and not the 607 editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ 608 Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on 609 improving the draft. Tolga's suggestion to provide a mechanism for 610 legacy interoperability served to expand the draft by 50%. In 611 addition, Tolga came up with the vCard attack. 613 8. References 615 8.1. Normative References 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, 619 DOI 10.17487/RFC2119, March 1997, 620 . 622 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 623 A., Peterson, J., Sparks, R., Handley, M., and E. 624 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 625 DOI 10.17487/RFC3261, June 2002, 626 . 628 [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason 629 Header Field for the Session Initiation Protocol (SIP)", 630 RFC 3326, DOI 10.17487/RFC3326, December 2002, 631 . 633 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 634 DOI 10.17487/RFC6350, August 2011, 635 . 637 [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to 638 Indicate Support of Features and Capabilities in the 639 Session Initiation Protocol (SIP)", RFC 6809, 640 DOI 10.17487/RFC6809, November 2012, 641 . 643 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 644 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 645 May 2017, . 647 8.2. Informative References 649 [BaseRate] 650 Bar-Hillel, M., "The Base-Rate Fallacy in Probability 651 Judgements", 4 1977, 652 . 654 [ITU.E.180.1998] 655 International Telecommunications Union, "Technical 656 characteristics of tones for the telephone service", 657 ITU Recommendation E.180/Q.35, March 1998. 659 [RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic 660 Network Media Services with SIP", RFC 4240, 661 DOI 10.17487/RFC4240, December 2005, 662 . 664 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 665 Description Protocol", RFC 4566, DOI 10.17487/RFC4566, 666 July 2006, . 668 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 669 Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, 670 January 2008, . 672 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 673 Telephone Identity Problem Statement and Requirements", 674 RFC 7340, DOI 10.17487/RFC7340, September 2014, 675 . 677 [RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", 678 RFC 8197, DOI 10.17487/RFC8197, July 2017, 679 . 681 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 682 "Authenticated Identity Management in the Session 683 Initiation Protocol (SIP)", RFC 8224, 684 DOI 10.17487/RFC8224, February 2018, 685 . 687 [SHAKEN] Alliance for Telecommunications Industry Solutions (ATIS) 688 and the SIP Forum, "Signature-based Handling of Asserted 689 information using toKENs (SHAKEN)", ATIS 1000074, 1 2017, 690 . 694 [SR-2275] Telcordia, "Bellcore Notes on the Networks", Telcordia SR- 695 2275, October 2000. 697 Author's Address 699 Eric W. Burger 700 Georgetown University 701 37th & O St, NW 702 Washington, DC 20057 703 USA 705 Email: eburger@standardstrack.com