draft-ietf-sipcore-rejected-00.txt   draft-ietf-sipcore-rejected-01.txt 
SIPCORE E. Burger SIPCORE E. Burger
Internet-Draft Georgetown University Internet-Draft Georgetown University
Intended status: Standards Track August 21, 2018 Intended status: Standards Track November 25, 2018
Expires: February 22, 2019 Expires: May 29, 2019
A Session Initiation Protocol (SIP) Response Code for Rejected Calls A Session Initiation Protocol (SIP) Response Code for Rejected Calls
draft-ietf-sipcore-rejected-00 draft-ietf-sipcore-rejected-01
Abstract Abstract
This document defines the 608 (Rejected) SIP response code. This This document defines the 608 (Rejected) SIP response code. This
response code enables calling parties to learn their call was response code enables calling parties to learn their call was
rejected by an intermediary and will not be answered. As a 6xx code, rejected by an intermediary and will not be answered. As a 6xx code,
the caller will be aware that future attempts to contact the same UAS the caller will be aware that future attempts to contact the same UAS
will be likely to fail. The present use case driving the need for will be likely to fail. The present use case driving the need for
the 608 response code is when the intermediary is an analytics the 608 response code is when the intermediary is an analytics
engine. In this case, the rejection is by a machine or other engine. In this case, the rejection is by a machine or other
process. This contrasts with the 607 (Unwanted) SIP response code, process. This contrasts with the 607 (Unwanted) SIP response code,
which a human at the target UAS indicated the call was not wanted. which a human at the target UAS indicated the call was not wanted.
In some jurisdictions this distinction is important and may have In some jurisdictions this distinction is important. This document
additional requirements beyond the 607 response code. Specifically, defines the use of the Call-Info header in 608 responses to enable
this document defines the use of the Call-Info header in 608 rejected callers to contact entities that blocked their calls in
responses to enable rejected callers to contact entities that blocked error.
their calls in error.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 22, 2019. This Internet-Draft will expire on May 29, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 7
3.2. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Legacy Interoperation . . . . . . . . . . . . . . . . . . 8
3.4. Announcement Requirements . . . . . . . . . . . . . . . . 9
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 15
5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The IETF has been addressing numerous issues surrounding how to The IETF has been addressing numerous issues surrounding how to
handle unwanted and, depending on the jurisdiction, illegal calls handle unwanted and, depending on the jurisdiction, illegal calls
[RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] [RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN]
address cryptographic signing and attestation, respectively, of address cryptographic signing and attestation, respectively, of
signaling to ensure the integrity and authenticity of the asserted signaling to ensure the integrity and authenticity of the asserted
identity. identity.
This document describes a new SIP response code, 608, which allows This document describes a new SIP response code, 608, which allows
skipping to change at page 2, line 50 skipping to change at page 3, line 21
Some call blocking services may return responses such as 604 (Does Some call blocking services may return responses such as 604 (Does
Not Exist Anywhere). This might be a strategy to attempt to get a Not Exist Anywhere). This might be a strategy to attempt to get a
destination's address removed from a calling database. However, destination's address removed from a calling database. However,
other network elements might interpret this to mean the user truly other network elements might interpret this to mean the user truly
does not exist and result in the user not being able to receive calls does not exist and result in the user not being able to receive calls
from anyone, even if wanted. As well, in many jurisdictions, from anyone, even if wanted. As well, in many jurisdictions,
providing false signaling is illegal. providing false signaling is illegal.
The 608 response code addresses this need of remediating falsely The 608 response code addresses this need of remediating falsely
blocked calls. Specifically, this code informs the UAC an blocked calls. Specifically, this code informs the UAC an
intermediary blocked the call and, to satisfy some jurisdictional intermediary blocked the call and, to satisfy jurisdictional
requirements for providing a redress mechanism, how to contact the requirements for providing a redress mechanism, how to contact the
operator of the intermediary. operator of the intermediary.
In the call handling ecosystem, users can explicitly reject a call or In the call handling ecosystem, users can explicitly reject a call or
later mark a call as being unwanted by issuing a 607 SIP response later mark a call as being unwanted by issuing a 607 SIP response
code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the operation code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the operation
of the 607 SIP response code. The UAS indicates the call was of the 607 SIP response code. The UAS indicates the call was
unwanted. As RFC8197 explains, not only does the called party desire unwanted. As RFC8197 explains, not only does the called party desire
to reject that call, they may wish to let their proxy know they might to reject that call, they may wish to let their proxy know they might
consider future calls from that source unwanted. Upon receipt of the consider future calls from that source unwanted by responding to the
607 response from the UAS, the proxy may send call information to a request with the 607 response. Upon receipt of the 607 response from
call analytics engine. For various reasons described in RFC8197, if the UAS, the proxy may send call information to a call analytics
a network operator receives multiple reports of unwanted calls, that engine. For various reasons described in RFC8197, if a network
may indicate the entity placing the calls is likely to be a source of operator receives multiple reports of unwanted calls, that may
indicate the entity placing the calls is likely to be a source of
unwanted calls for many people. As such, other users of the service unwanted calls for many people. As such, other users of the service
provider's service may wish the service provider to automatically provider's service may wish the service provider to automatically
reject calls on their behalf based on that and other analytics. reject calls on their behalf based on that and other analytics.
Another value of the 607 rejection is presuming the proxy forwards Another value of the 607 rejection is presuming the proxy forwards
the response code to the UAC, the calling UAC or intervening proxies the response code to the UAC, the calling UAC or intervening proxies
know the user is not interested in receiving calls from that sender. will also learn the user is not interested in receiving calls from
that sender.
+-----------+ +-----------+
| Call | | Call |
| Analytics | | Analytics |
| Engine | | Engine |
+-----------+ +-----------+
^ | (likely not SIP) ^ | (likely not SIP)
| v | v
+-----------+ +-----------+
+-----+ 607 | Called | 607 +-----+ +-----+ 607 | Called | 607 +-----+
skipping to change at page 3, line 47 skipping to change at page 4, line 28
Figure 1: Unwanted (607) Call Flow Figure 1: Unwanted (607) Call Flow
For calls rejected with a 607 from a legitimate caller, receiving a For calls rejected with a 607 from a legitimate caller, receiving a
607 response code can inform the caller to stop attempting to call 607 response code can inform the caller to stop attempting to call
the user. Moreover, if the legitimate caller believes the user is the user. Moreover, if the legitimate caller believes the user is
rejecting their calls in error, they can use other channels to rejecting their calls in error, they can use other channels to
contact the user. For example, if a pharmacy calls a user to let contact the user. For example, if a pharmacy calls a user to let
them know their prescription is available for pickup and the user them know their prescription is available for pickup and the user
mistakenly thinks the call is unwanted and issues a 607 response mistakenly thinks the call is unwanted and issues a 607 response
code, the pharmacy, having an existing relationship with the code, the pharmacy, having an existing relationship with the
customer, can send the user an email, also noting they might consider customer, can send the user an email, also noting the customer might
not rejecting their calls in the future. consider not rejecting their calls in the future.
Moreover, many systems that allow the user to mark the call unwanted Moreover, many systems that allow the user to mark the call unwanted
(e.g., with the 607 response code) also allow the user to change (e.g., with the 607 response code) also allow the user to change
their mind and unmark such calls. This is relatively easy to their mind and unmark such calls. This is relatively easy to
implement as the user usually has a direct relationship with the implement as the user usually has a direct relationship with the
provider of the blocking service. provider of the blocking service.
+--------+ +-----------+ +--------+ +-----------+
| Called | | Call | | Called | | Call |
+-----+ | Party | | Analytics | +-----+ +-----+ | Party | | Analytics | +-----+
skipping to change at page 4, line 37 skipping to change at page 5, line 34
However, things get more complicated if an intermediary, such as a However, things get more complicated if an intermediary, such as a
third-party provider of call management services that classify calls third-party provider of call management services that classify calls
based on the relative likelihood the call is unwanted, misidentifies based on the relative likelihood the call is unwanted, misidentifies
the call as unwanted. Figure 3 shows this case. Note the UAS the call as unwanted. Figure 3 shows this case. Note the UAS
typically does not receive an INVITE as the proxy rejects the call on typically does not receive an INVITE as the proxy rejects the call on
behalf of the user. In this situation, it would be beneficial for behalf of the user. In this situation, it would be beneficial for
the caller to be able to learn who rejected the call, so they might the caller to be able to learn who rejected the call, so they might
be able to correct the misidentification. be able to correct the misidentification.
In this situation, one might be tempted to have the intermediary use In this situation, one might be tempted to have the intermediary use
the 607 response code. 607 indicates to the caller the subscriber the 607 response code. 607 indicates to the caller the subscriber did
did not get the call and they do not want the call. However, RFC8197 not get the call and they do not want the call. However, RFC8197
specifies that one of the uses of 607 is to inform analytics engines specifies that one of the uses of 607 is to inform analytics engines
that a user (human) has rejected a call. The problem here is network that a user (human) has rejected a call. The problem here is network
elements downstream from the intermediary might interpret the 607 as elements downstream from the intermediary might interpret the 607 as
a user (human) marking the call as unwanted, as opposed to a a user (human) marking the call as unwanted, as opposed to a
statistical, machine learning, vulnerable to the base rate fallacy statistical, machine learning, vulnerable to the base rate fallacy
[BaseRate] algorithm rejecting the call. In other words, those [BaseRate] algorithm rejecting the call. In other words, those
downstream entities should not be relying on another entity downstream entities should not be relying on another entity
'deciding' the call is unwanted. By distinguishing between a (human) 'deciding' the call is unwanted. By distinguishing between a (human)
user rejection and an intermediary's statistical rejection, a user rejection and an intermediary's statistical rejection, a
downstream network element that sees a 607 response code can weight downstream network element that sees a 607 response code can weight
skipping to change at page 5, line 41 skipping to change at page 6, line 41
blocked in error? The reason is whilst there is an existing blocked in error? The reason is whilst there is an existing
relationship between the customer (called party) and the analytics relationship between the customer (called party) and the analytics
service provider, it is unlikely there is a relationship between the service provider, it is unlikely there is a relationship between the
caller and the analytics service provider. Moreover, there are caller and the analytics service provider. Moreover, there are
numerous call blocking providers in the ecosystem. As such, we need numerous call blocking providers in the ecosystem. As such, we need
a mechanism for indicating an intermediary rejected a call while a mechanism for indicating an intermediary rejected a call while
providing contact information for the operator of the intermediary providing contact information for the operator of the intermediary
that provides call rejection services to the called party, without that provides call rejection services to the called party, without
exposing the target user's contact information. exposing the target user's contact information.
The protocol described in this document uses existing IETF protocol
mechanisms for specifying the redress mechanism. Specifically, we
use jCard [RFC7095] encoding of the redress address. For integrity
protection, we sign the redress address. Conveniently, we use jCard
rather than vCard [RFC6350] as we have a standard marshaling
mechanism for creating a canonical representation of a JSON [RFC8259]
object, such as a jCard, and a standard presentation format for such
an object, namely JWS [RFC7515]. The SIP community is familiar with
this concept as it is the mechanism used by STIR [RFC8224].
2. Terminology 2. Terminology
This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only
when, they appear in all capitals, as shown here. when, they appear in all capitals, as shown here.
3. Protocol Operation 3. Protocol Operation
For clarity, this section uses the term 'intermediary' as the entity For clarity, this section uses the term 'intermediary' as the entity
skipping to change at page 6, line 47 skipping to change at page 8, line 7
issue the 608 as the value of the "cause" parameter of a SIP reason- issue the 608 as the value of the "cause" parameter of a SIP reason-
value in a Reason header field [RFC3326]. value in a Reason header field [RFC3326].
Unless there are indicators the calling party will use the contents Unless there are indicators the calling party will use the contents
of the Call-Info header for malicious purposes (see Section 6), if an of the Call-Info header for malicious purposes (see Section 6), if an
intermediary issues a 608 code, the intermediary MUST include a Call- intermediary issues a 608 code, the intermediary MUST include a Call-
Info header in the response. Info header in the response.
If there is a Call-Info header, it MUST have the 'purpose' parameter If there is a Call-Info header, it MUST have the 'purpose' parameter
of 'card'. The value of the Call-Info header MUST refer to a valid of 'card'. The value of the Call-Info header MUST refer to a valid
vCard [RFC6350] object. JWS [RFC7515] encoding of a jCard [RFC7095] object. As for the
signature algorithms allowed and policies surrounding the issuance
and publication of public and private keys, one could expect to see
policies such as defined by SHAKEN [SHAKEN]. However, the
specification for the signature algorithm and policies for the
asserted keys are beyond the scope of this document.
The vCard referenced in the Call-Info header MUST include at least The jCard referenced in the Call-Info header MUST include at least
one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this one of the URL, EMAIL, TEL, or ADR properties. UACs supporting this
specification MUST be prepared to receive a full vCard. Call specification MUST be prepared to receive a full jCard. Call
originators (at the UAC) can use the information returned by the originators (at the UAC) can use the information returned by the
vCard to contact the intermediary that rejected the call to appeal jCard to contact the intermediary that rejected the call to appeal
the intermediary's blocking of the call attempt. What the the intermediary's blocking of the call attempt. What the
intermediary does if the blocked caller contacts the intermediary is intermediary does if the blocked caller contacts the intermediary is
outside the scope of this document. outside the scope of this document.
Proxies need to be mindful that a downstream intermediary may reject Proxies need to be mindful that a downstream intermediary may reject
the attempt with a 608 while other paths may still be in progress. the attempt with a 608 while other paths may still be in progress.
In this situation, the requirements stated in Section 16.7 of RFC3261 In this situation, the requirements stated in Section 16.7 of RFC3261
[RFC3261] apply. Specifically, the proxy should cancel pending [RFC3261] apply. Specifically, the proxy should cancel pending
transactions and must not create any new branches. Note this is not transactions and must not create any new branches. Note this is not
a new requirement but simply pointing out the existing 6xx protocol a new requirement but simply pointing out the existing 6xx protocol
skipping to change at page 8, line 11 skipping to change at page 9, line 23
knows this is the case as the INVITE request will not have the knows this is the case as the INVITE request will not have the
sip.608 feature capability. In this case, one can consider the sip.608 feature capability. In this case, one can consider the
intermediary to be the element 'inserting' a virtual sip.608 feature intermediary to be the element 'inserting' a virtual sip.608 feature
capability. As such, the intermediary MUST play the announcement, capability. As such, the intermediary MUST play the announcement,
with the caveats described in Section 3.4 and Section 6. with the caveats described in Section 3.4 and Section 6.
Now we take the case where a network element that understands the 608 Now we take the case where a network element that understands the 608
response code receives an INVITE for further processing. A network response code receives an INVITE for further processing. A network
element conforming with this specification MUST insert the sip.608 element conforming with this specification MUST insert the sip.608
feature capability, per the behaviors described in Section 4.2 of feature capability, per the behaviors described in Section 4.2 of
[RFC6809]. This information will be in the vCard referenced by the [RFC6809]. This information will be in the JWS of the jCard
Call-Info header in the 608 response message. Note this referenced by the Call-Info header in the 608 response message. Note
specification does not specify the mechanism for such notification to this specification does not specify the mechanism for such
the UAC (see Section 3.4). notification to the UAC (see Section 3.4).
Do note that even if a network element plays an announcement Do note that even if a network element plays an announcement
describing the contents of the 608 response message, the network describing the contents of the 608 response message, the network
element MUST also send the 608 response code message as the final element MUST also send the 608 response code message as the final
response to the INVITE. response to the INVITE.
One aspect of using a feature capability is only the network elements One aspect of using a feature capability is only the network elements
that will consume (UAC) or play an announcement (media gateway, SBC, that will consume (UAC) or play an announcement (media gateway, SBC,
or proxy) need understand the sip.608 feature capability. All other or proxy) need understand the sip.608 feature capability. All other
(existing) infrastructure can remain without modification, assuming (existing) infrastructure can remain without modification, assuming
skipping to change at page 10, line 4 skipping to change at page 11, line 35
Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC Y4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtC
A;info=<http://cert.example2.net/example.cert>;alg=ES256 A;info=<http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153 Content-Length: 153
v=0 v=0
o=- 13103070023943130 1 IN IP4 192.0.2.177 o=- 13103070023943130 1 IN IP4 192.0.2.177
c=IN IP4 192.0.2.177 c=IN IP4 192.0.2.177
t=0 0 t=0 0
m=audio 54242 RTP/AVP 0 m=audio 54242 RTP/AVP 0
a=sendrecv a=sendrecv
An intermediary could reply: An intermediary could reply:
SIP/2.0 608 Rejected SIP/2.0 608 Rejected
Via: SIP/2.0/UDP 192.0.2.177:60012;branch=z9hG4bK-524287-1 Via: SIP/2.0/UDP 192.0.2.177:60012;branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40 From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40
To: <sip:+12155551213@tel.example1.net> To: <sip:+12155551213@tel.example1.net>
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE CSeq: 2 INVITE
Call-Info: <https://blocker.example.net/complaints.vcf>;purpose=card Call-Info: <https://blocker.example.net/complaints.json>;purpose=card
A minimal vCard, in this example at https://blocker.example.net/ A minimal jCard could be:
complaints.vcf, could contain:
BEGIN:VCARD ["vcard",
VERSION:4.0 [
FN:Robocall Adjudication ["version", {}, "text", "4.0"],
EMAIL;TYPE=work:bitbucket@blocker.example.net ["fn", {}, "text", "Robocall Adjudication"],
END:VCARD ["email", {"type":"work"},
"text", "bitbucket@blocker.example.net"]
]
]
In base64:
WyJ2Y2FyZCIsCiAgWwogICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJd
LAogICAgWyJmbiIsIHt9LCAidGV4dCIsICJSb2JvY2FsbCBBZGp1ZGljYXRpb24i
XSwKICAgIFsiZW1haWwiLCB7InR5cGUiOiJ3b3JrIn0sICJ0ZXh0IiwgImJpdGJ1
Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICBdCl0K
The JWS header of this example jCard could be:
{ {"alg":"ES256"},
{"typ":"vcard+json"},
{"x5u":"https://certs.example.net/reject_key.cer"} }
In base64:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo=
The resulting JWS, presuming the base64 encoding of the ECDSA P-256
SHA-256 digital signature using the certificate mentioned above is,
the final string after the period in the example below, stored at
https://blocker.example.net/complaints.json, the file could thus
contain:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo=.WyJ2Y2FyZCIsCiAgWwogICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQ
uMCJdLAogICAgWyJmbiIsIHt9LCAidGV4dCIsICJSb2JvY2FsbCBBZGp1ZGljYXR
pb24iXSwKICAgIFsiZW1haWwiLCB7InR5cGUiOiJ3b3JrIn0sICJ0ZXh0IiwgImJ
pdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICBdCl0K.OSaG/DGW8jxfWM
Z+cExnmhCPEXxIg+dEiJakRKD/E4KZak8PsEv/5Bh0bz9KMv8d+o6JnT76v9cuk+
d3CxE3HW
For an intermediary that provides a Web site for adjudication, the For an intermediary that provides a Web site for adjudication, the
vCard could contain: jCard could contain the following. Note the calculation of the JWS
is not shown; the URI reference in the Call-Info header would be to
the JWS of the signed jCard.
BEGIN:VCARD ["vcard",
VERSION:4.0 [
FN:Robocall Adjudication ["version", {}, "text", "4.0"],
URL;TYPE=work:https://blocker.example.net/adjudication-form ["fn", {}, "text", "Robocall Adjudication"],
END:VCARD ["url", {"type":"work"},
"text", "https://blocker.example.net/adjudication-form"]
]
]
For an intermediary that provides a telephone number and a postal For an intermediary that provides a telephone number and a postal
address, the vCard could contain: address, the jCard could contain the following. Note the calculation
of the JWS is not shown; the URI reference in the Call-Info header
would be to the JWS of the signed jCard.
BEGIN:VCARD ["vcard",
VERSION:4.0 [
FN:Robocall Adjudication ["version", {}, "text", "4.0"],
ADR;TYPE=work;Argument Clinic;12 Main St;Anytown;AP;000000;Somewhere ["fn", {}, "text", "Robocall Adjudication"],
TEL;VALUE=uri;TYPE=work:tel:+1-555-555-1212 ["adr", {"type":"work"}, "text",
END:VCARD ["Argument Clinic",
"12 Main St","Anytown","AP","000000","Somecountry"]
]
["tel", {"type":"work"}, "uri", "tel:+1-555-555-1212"]
]
]
Note that it is up to the UAC to decide which vCard contact modality, Note that it is up to the UAC to decide which jCard contact modality,
if any, it will use. if any, it will use.
Figure 5 depicts a call flow illustrating legacy interoperability. Figure 5 depicts a call flow illustrating legacy interoperability.
In this non-normative example, we see a UAC that does not support the In this non-normative example, we see a UAC that does not support the
full semantics for 608. However, there is an SBC that does support full semantics for 608. However, there is an SBC that does support
608. Per RFC6809 [RFC6809], the SBC can insert "sip.608" into the 608. Per RFC6809 [RFC6809], the SBC can insert "sip.608" into the
Feature-Caps header for the INVITE. When the intermediary, labeled Feature-Caps header for the INVITE. When the intermediary, labeled
"Called Party Proxy" in the figure, rejects the call, it knows it can "Called Party Proxy" in the figure, rejects the call, it knows it can
simply perform the processing described in this document. Since the simply perform the processing described in this document. Since the
intermediary saw the sip.608 feature capability, it knows it does not intermediary saw the sip.608 feature capability, it knows it does not
skipping to change at page 11, line 46 skipping to change at page 14, line 43
Figure 5: Legacy Operation Figure 5: Legacy Operation
When the SBC receives the 608 response code, it correlates that with When the SBC receives the 608 response code, it correlates that with
the original INVITE from the UAC. The SBC remembers that it inserted the original INVITE from the UAC. The SBC remembers that it inserted
the sip.608 feature capability, which means it is responsible for the sip.608 feature capability, which means it is responsible for
somehow alerting the UAC the call failed and whom to contact. At somehow alerting the UAC the call failed and whom to contact. At
this point the SBC can play a prompt, either natively or through a this point the SBC can play a prompt, either natively or through a
mechanism such as NETANN [RFC4240], that sends the relevant mechanism such as NETANN [RFC4240], that sends the relevant
information in the appropriate media to the UAC. information in the appropriate media to the UAC.
As an example, the SBC could extract the FN and TEL vCard fields and As an example, the SBC could extract the FN and TEL jCard fields and
play something like a special information tone (see Telcordia SR-2275 play something like a special information tone (see Telcordia SR-2275
[SR-2275] section 6.21.2.1 or ITU-T E.180 [ITU.E.180.1998] section [SR-2275] section 6.21.2.1 or ITU-T E.180 [ITU.E.180.1998] section
7), followed by "Your call has been rejected by ...", followed by a 7), followed by "Your call has been rejected by ...", followed by a
text-to-speech translation of the FN text, followed by "You can reach text-to-speech translation of the FN text, followed by "You can reach
them on", followed by a text-to-speech translation of the telephone them on", followed by a text-to-speech translation of the telephone
number in the TEL field. number in the TEL field.
Note the SBC also still sends the full 608 response code, including Note the SBC also still sends the full 608 response code, including
the Call-Info header, towards the UAC. the Call-Info header, towards the UAC.
skipping to change at page 12, line 49 skipping to change at page 15, line 44
Reference: [RFCXXXX] Reference: [RFCXXXX]
6. Security Considerations 6. Security Considerations
Intermediary operators need to be mindful of whom they are sending Intermediary operators need to be mindful of whom they are sending
the 608 response to. There is a risk that a truly malicious caller the 608 response to. There is a risk that a truly malicious caller
is being rejected. This raises two issues. The first is the caller, is being rejected. This raises two issues. The first is the caller,
being alerted their call is being automatically rejected, may change being alerted their call is being automatically rejected, may change
their call behavior to defeat call blocking systems. The second, and their call behavior to defeat call blocking systems. The second, and
more significant risk, is that by providing a contact modality in the more significant risk, is that by providing a contact in the Call-
Call-Info field, the intermediary may be giving the malicious caller Info field, the intermediary may be giving the malicious caller a
a vector for attack. In other words, the intermediary will be vector for attack. In other words, the intermediary will be
publishing an address that a malicious actor may use to launch an publishing an address that a malicious actor may use to launch an
attack on the intermediary. Because of this, intermediary operators attack on the intermediary. Because of this, intermediary operators
may wish to configure their response to only include a Call-Info may wish to configure their response to only include a Call-Info
field for INVITE or other initiating methods that are signed and pass field for INVITE or other initiating methods that are signed and pass
validation by STIR [RFC8224]. validation by STIR [RFC8224].
Another risk is for an attacker to purposely not include the sip.608 Another risk is for an attacker to purposely not include the sip.608
feature capability in a flood of INVITE requests, with the first Via feature capability in a flood of INVITE requests, direct those
header to a victim device. Worse, the attacker can format an SDP requests to proxies known to insert the sip.608 feature, and direct
[RFC4566] body with the IP address of a victim device in a c-line. the SDP to a victim device. Because the mechanism described here can
Because the mechanism described here can result in an audio file result in an audio file being sent to the target of the Contact
being sent to the target of the Contact header, an attacker could use header, an attacker could use the mechanism described by this
the mechanism described by this document as an amplification attack, document as an amplification attack, given a SIP INVITE can be under
given a SIP INVITE can be under 1 kilobyte and an audio file can be 1 kilobyte and an audio file can be hundreds of kilobytes. One
hundreds of kilobytes. One remediation for this is for intermediate remediation for this is for devices that insert a sip.608 feature
devices that insert a sip.608 feature capability only transmit media capability only transmit media to what is highly likely to be the
back to what is highly likely to be the actual source of the call actual source of the call attempt. A method for this is to only play
attempt. A method for this is to only play media in response to an media in response to an INVITE that is signed and passed validation
INVITE that is signed and passed validation by STIR [RFC8224]. by STIR [RFC8224].
Yet another risk is a malicious entity can generate a 608 response Yet another risk is a malicious entity or the intermediary itself can
with a vCard referring to a malicious agent. For example, the generate a malicious 608 response with a jCard referring to a
recipient of a 608 may receive a TEL URI in the vCard. When the malicious agent. For example, the recipient of a 608 may receive a
recipient calls that address, the malicious agent could ask for TEL URI in the vCard. When the recipient calls that address, the
personally identifying information. However, instead of using that malicious agent could ask for personally identifying information.
information to verify the recipient's identity, they are pharming the However, instead of using that information to verify the recipient's
information for nefarious ends. As such, we strongly recommend the identity, they are pharming the information for nefarious ends. As
recipient validates to whom they are communicating with if asking to such, we strongly recommend the recipient validates to whom they are
adjudicate an erroneously rejected call attempt. Unlike the INVITE communicating with if asking to adjudicate an erroneously rejected
case where we can suggest only responding to STIR-validated requests, call attempt. Since we may also be concerned about intermediate
there is no integrity protection of vCard data in such a way one can nodes modifying contact information, we can address both of these
trace back the provenance of the data. That is an opportunity for issues with a single solution. The remediation is to require the
future work. intermediary to sign the jCard. Signing the jCard provides integrity
protection. In addition, one can imagine mechanisms such as used by
SHAKEN [SHAKEN] to use signing certificate issuance as a mechanism
for traceback to the entity issuing the jCard, for example tying the
identity of the subject of the certificate to the To field of the
initial SIP request, as if the intermediary was vouching for the From
field of a SIP request with that identity.
7. Acknowledgements 7. Acknowledgements
This document liberally lifts from [RFC8197] in its text and This document liberally lifts from [RFC8197] in its text and
structure. However, the mechanism and purpose of 608 is quite structure. However, the mechanism and purpose of 608 is quite
different than 607. Any errors are the current editor's and not the different than 607. Any errors are the current editor's and not the
editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ editor of RFC8197. Thanks also go to Ken Carlberg of the FCC, Russ
Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on Housley, Paul Kyzivat, and Tolga Asveren for their suggestions on
improving the draft. Tolga's suggestion to provide a mechanism for improving the draft. Tolga's suggestion to provide a mechanism for
legacy interoperability served to expand the draft by 50%. In legacy interoperability served to expand the draft by 50%. In
addition, Tolga came up with the vCard attack. addition, Tolga came up with the jCard attack.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 14, line 25 skipping to change at page 17, line 25
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason [RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)", Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, DOI 10.17487/RFC3326, December 2002, RFC 3326, DOI 10.17487/RFC3326, December 2002,
<https://www.rfc-editor.org/info/rfc3326>. <https://www.rfc-editor.org/info/rfc3326>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to [RFC6809] Holmberg, C., Sedlacek, I., and H. Kaplan, "Mechanism to
Indicate Support of Features and Capabilities in the Indicate Support of Features and Capabilities in the
Session Initiation Protocol (SIP)", RFC 6809, Session Initiation Protocol (SIP)", RFC 6809,
DOI 10.17487/RFC6809, November 2012, DOI 10.17487/RFC6809, November 2012,
<https://www.rfc-editor.org/info/rfc6809>. <https://www.rfc-editor.org/info/rfc6809>.
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095,
DOI 10.17487/RFC7095, January 2014,
<https://www.rfc-editor.org/info/rfc7095>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References 8.2. Informative References
[BaseRate] [BaseRate]
Bar-Hillel, M., "The Base-Rate Fallacy in Probability Bar-Hillel, M., "The Base-Rate Fallacy in Probability
Judgements", 4 1977, Judgements", 4 1977,
<http://www.dtic.mil/get-tr-doc/pdf?AD=ADA045772>. <http://www.dtic.mil/get-tr-doc/pdf?AD=ADA045772>.
skipping to change at page 15, line 18 skipping to change at page 18, line 23
<https://www.rfc-editor.org/info/rfc4240>. <https://www.rfc-editor.org/info/rfc4240>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <https://www.rfc-editor.org/info/rfc4566>. July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039, Protocol (SIP) and Spam", RFC 5039, DOI 10.17487/RFC5039,
January 2008, <https://www.rfc-editor.org/info/rfc5039>. January 2008, <https://www.rfc-editor.org/info/rfc5039>.
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
[RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls", [RFC8197] Schulzrinne, H., "A SIP Response Code for Unwanted Calls",
RFC 8197, DOI 10.17487/RFC8197, July 2017, RFC 8197, DOI 10.17487/RFC8197, July 2017,
<https://www.rfc-editor.org/info/rfc8197>. <https://www.rfc-editor.org/info/rfc8197>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[SHAKEN] Alliance for Telecommunications Industry Solutions (ATIS) [SHAKEN] Alliance for Telecommunications Industry Solutions (ATIS)
and the SIP Forum, "Signature-based Handling of Asserted and the SIP Forum, "Signature-based Handling of Asserted
information using toKENs (SHAKEN)", ATIS 1000074, 1 2017, information using toKENs (SHAKEN)", ATIS 1000074, 1 2017,
<https://www.sipforum.org/download/sip-forum-twg-10- <https://www.sipforum.org/download/sip-forum-twg-10-
signature-based-handling-of-asserted-information-using- signature-based-handling-of-asserted-information-using-
tokens-shaken-pdf/?wpdmdl=2813>. tokens-shaken-pdf/?wpdmdl=2813>.
[SR-2275] Telcordia, "Bellcore Notes on the Networks", Telcordia SR- [SR-2275] Telcordia, "Bellcore Notes on the Networks", Telcordia SR-
2275, October 2000. 2275, October 2000.
 End of changes. 34 change blocks. 
85 lines changed or deleted 189 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/