draft-ietf-sipcore-rejected-05.txt   draft-ietf-sipcore-rejected-06.txt 
SIPCORE E. Burger SIPCORE E. Burger
Internet-Draft Georgetown University Internet-Draft Georgetown University
Intended status: Standards Track B. Nagda Intended status: Standards Track B. Nagda
Expires: October 2, 2019 Massachusetts Institute of Technology Expires: October 9, 2019 Massachusetts Institute of Technology
March 31, 2019 April 7, 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-05 draft-ietf-sipcore-rejected-06
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 that an intermediary response code enables calling parties to learn that an intermediary
rejected their call attempt. The call will not be answered. As a rejected their call attempt. The call will not be answered. As a
6xx code, the caller will be aware that future attempts to contact 6xx code, the caller will be aware that future attempts to contact
the same UAS will likely fail. The present use case driving the need the same UAS will likely fail. The present use case driving the need
for the 608 response code is when the intermediary is an analytics for 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. This document In some jurisdictions this distinction is important. This document
also defines the use of the Call-Info header in 608 responses to also defines the use of the Call-Info header field in 608 responses
enable rejected callers to contact entities that blocked their calls to enable rejected callers to contact entities that blocked their
in error. This provides a remediation mechanism for legal callers calls in error. This provides a remediation mechanism for legal
that find their calls blocked. callers that find their calls blocked.
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 October 2, 2019. This Internet-Draft will expire on October 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 3, line 40 skipping to change at page 3, line 40
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 try to get a Not Exist Anywhere). This might be a strategy to try 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 also interpret this to mean the user other network elements might also interpret this to mean the user
truly does not exist and might result in the user not being able to truly does not exist and might result in the user not being able to
receive calls from anyone, even if wanted. In many jurisdictions, receive calls from anyone, even if wanted. In many jurisdictions,
providing such false signaling is also illegal. providing such false signaling is also 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 that an blocked calls. Specifically, this code informs the SIP User Agent
intermediary blocked the call and provides a redress mechanism that Client (UAC) that an intermediary blocked the call and provides a
allows callers to contact the operator of the intermediary. redress mechanism that allows callers to contact the operator of the
intermediary.
In the current call handling ecosystem, users can explicitly reject a In the current call handling ecosystem, users can explicitly reject a
call or later mark a call as being unwanted by issuing a 607 SIP call or later mark a call as being unwanted by issuing a 607 SIP
response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 show the
operation of the 607 SIP response code. The UAS indicates the call operation of the 607 SIP response code. The UAS indicates the call
was unwanted. As RFC8197 explains, not only does the called party was unwanted. As RFC8197 explains, not only does the called party
desire to reject that call, they can let their proxy know that they desire to reject that call, they can let their proxy know that they
consider future calls from that source unwanted. Upon receipt of the consider future calls from that source unwanted. Upon receipt of the
607 response from the UAS, the proxy may send call information to a 607 response from the UAS, the proxy may send call information to a
call analytics engine. For various reasons described in RFC8197, if call analytics engine. For various reasons described in RFC8197, if
a network operator receives multiple reports of unwanted calls, that a network operator receives multiple reports of unwanted calls, that
may indicate that the entity placing the calls is likely to be a may indicate that the entity placing the calls is likely to be a
source of unwanted calls for many people. As such, other customers source of unwanted calls for many people. As such, other customers
of the service provider may want the service provider to of the service provider may want the service provider to
skipping to change at page 5, line 48 skipping to change at page 6, line 4
| UAC | <--------- | Party | | UAS | | UAC | <--------- | Party | | UAS |
+-----+ | Proxy | +-----+ +-----+ | Proxy | +-----+
+-----------+ +-----------+
Figure 3: Rejected (608) Call Flow Figure 3: Rejected (608) Call Flow
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
does not want the call. However, RFC8197 specifies that one of the does not want the call. However, RFC8197 specifies that one of the
uses of 607 is to inform analytics engines that a user (human) has uses of 607 is to inform analytics engines that a user (human) has
rejected a call. The problem here is network elements downstream rejected a call. The problem here is that network elements
from the intermediary might interpret the 607 as a user (human) downstream from the intermediary might interpret the 607 as coming
marking the call as unwanted, as opposed to a statistical, machine from a user (human) that has marked the call as unwanted, as opposed
learning, vulnerable to the base rate fallacy [BaseRate] algorithm to coming from an algorithm using statistics or machine learning to
rejecting the call. In other words, those downstream entities should reject the call. An algorithm can be vulnerable to the base rate
not be relying on another entity 'deciding' the call is unwanted. By fallacy base rate fallacy [BaseRate] algorithm rejecting the call.
distinguishing between a (human) user rejection and an intermediary In other words, those downstream entities should not rely on another
engine's statistical rejection, a downstream network element that entity 'deciding' the call is unwanted. By distinguishing between a
sees a 607 response code can weight it as a human rejection in its (human) user rejection and an intermediary engine's statistical
call analytics. rejection, a downstream network element that sees a 607 response code
can weight it as a human rejection in its call analytics.
It is useful for blocked callers to have a redress mechanism. One It is useful for blocked callers to have a redress mechanism. One
can imagine that some jurisdictions will require it. However, we can imagine that some jurisdictions will require it. However, we
must be mindful that most of the calls that will be blocked will, in must be mindful that most of the calls that will be blocked will, in
fact, be illegal and eligible for blocking. Thus, providing fact, be illegal and eligible for blocking. Thus, providing
alternate contact information for a user would be counterproductive alternate contact information for a user would be counterproductive
to protecting that user from illegal communications. This is another to protecting that user from illegal communications. This is another
reason we do not propose to simply allow alternate contact reason we do not propose to simply allow alternate contact
information in a 607 response message. information in a 607 response message.
skipping to change at page 6, line 35 skipping to change at page 6, line 37
blocked in error? The reason is while there is an existing blocked in error? The reason is while 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 that also a mechanism for indicating an intermediary rejected a call that also
provides contact information for the operator of that intermediary, provides contact information for the operator of that intermediary,
without exposing the target user's contact information. without exposing the target user's contact information.
The protocol described in this document uses existing IETF protocol The protocol described in this document uses existing IETF protocol
mechanisms for specifying the redress mechanism. In the SIP header mechanisms for specifying the redress mechanism. In the Call-Info
passed back to the UAC, we send additional information specifying a header passed back to the UAC, we send additional information
redress address. We choose to encode the redress address using jCard specifying a redress address. We choose to encode the redress
[RFC7095]. Conveniently, we use jCard rather than vCard [RFC6350] as address using jCard [RFC7095]. Conveniently, we use jCard rather
we have a standard marshaling mechanism for creating a canonical than vCard [RFC6350] as we have a standard marshaling mechanism for
representation of a JSON [RFC8259] object, such as a jCard, and a creating a canonical representation of a JSON [RFC8259] object, such
standard presentation format for such an object, namely JWS as a jCard, and a standard presentation format for such an object,
[RFC7515]. The SIP community is familiar with this concept as it is namely JWS [RFC7515]. The SIP community is familiar with this
the mechanism used by STIR [RFC8224]. concept as it is the mechanism used by STIR [RFC8224].
The jCard encoding might seem unnecessary at first, but it is The jCard encoding might seem unnecessary at first, but it is
essential to preventing potential network attacks. Suppose, for essential to preventing potential network attacks. Suppose, for
example, that the redress address was simply passed as a header example, that the redress address was simply passed as a header
value. One can imagine an adverse agent that maliciously spoofs a value. One can imagine an adverse agent that maliciously spoofs a
608 response with the same redress address to a large number of 608 response with the same redress address to a large number of
active callers, who may then all send redress requests to the active callers, who may then all send redress requests to the
specified address (the basis for a denial-of-service attack). The specified address (the basis for a denial-of-service attack). The
process would occur as follows: (1) a malicious agent senses INVITE process would occur as follows: (1) a malicious agent senses INVITE
requests from a variety UACs and (2) spoofs 608 responses with an requests from a variety UACs and (2) spoofs 608 responses with an
unsigned redress address before the intended receivers can respond, unsigned redress address before the intended receivers can respond,
causing (3) the UACs to all contact the redress address at once. The causing (3) the UACs to all contact the redress address at once. The
jCard encoding allows the UAC to verify the blocking intermediary's jCard encoding allows the UAC to verify the blocking intermediary's
identity before contacting the redress address. This guards against identity before contacting the redress address. This guards against
a malicious agent spoofing 608 responses, preventing the denial-of- a malicious agent spoofing 608 responses, preventing the denial-of-
service attack. Thus if the jCard address is unreachable or service attack. Thus, if the jCard address is unreachable or
undecipherable, either (1) a malicious agent is lying about the jCard undecipherable, either (1) a malicious agent is lying about the jCard
or (2) the redress mechanism is misconfigured. or (2) the redress mechanism is misconfigured.
2. Terminology 2. Terminology
This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only "OPTIONAL" in this document are to be interpreted as described in BCP
when, they appear in all capitals, as shown here. 14 [RFC2119][RFC8174] when, and only 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
that acts as a SIP User Agent Server (UAS) on behalf of the user in that acts as a SIP User Agent Server (UAS) on behalf of the user in
the network, as opposed to the user's UAS (colloquially, but not the network, as opposed to the user's UAS (colloquially, but not
necessarily, their phone). The intermediary could be a back-to-back necessarily, their phone). The intermediary could be a back-to-back
user agent (B2BUA) or a SIP Proxy. user agent (B2BUA) or a SIP Proxy.
Figure 4 shows an overview of the call flow for a rejected call. Figure 4 shows an overview of the call flow for a rejected call.
skipping to change at page 8, line 15 skipping to change at page 8, line 15
3.1. Intermediary Operation 3.1. Intermediary Operation
An intermediary MAY issue the 608 response code in a failure response An intermediary MAY issue the 608 response code in a failure response
for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP for an INVITE, MESSAGE, SUBSCRIBE, or other out-of-dialog SIP
[RFC3261] request to indicate that an intermediary rejected the [RFC3261] request to indicate that an intermediary rejected the
offered communication as unwanted by the user. An intermediary MAY offered communication as unwanted by the user. An intermediary MAY
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].
If an intermediary issues a 608 code and there are not indicators the If an intermediary issues a 608 code and there are not indicators the
calling party will use the contents of the Call-Info header for calling party will use the contents of the Call-Info header field for
malicious purposes (see Section 6), the intermediary MUST include a malicious purposes (see Section 6), the intermediary MUST include a
Call-Info header in the response. Call-Info header field in the response.
If there is a Call-Info header, it MUST have the 'purpose' parameter If there is a Call-Info header field, it MUST have the 'purpose'
of 'jwscard'. The value of the Call-Info header MUST refer to a parameter of 'jwscard'. The value of the Call-Info header field MUST
valid JWS [RFC7515] encoding of a jCard [RFC7095] object. refer to a valid JWS [RFC7515] encoding of a jCard [RFC7095] object.
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
mechanism in SIP. mechanism in SIP.
3.2. jCard Construction 3.2. jCard Construction
skipping to change at page 9, line 21 skipping to change at page 9, line 21
3.2.3. JWS Signature 3.2.3. JWS Signature
JWS [RFC7515] specifies the procedure for calculating the signature JWS [RFC7515] specifies the procedure for calculating the signature
over the jCard JWT. Section 4 of this document has a detailed over the jCard JWT. Section 4 of this document has a detailed
example on constructing the JWS, including the signature. example on constructing the JWS, including the signature.
3.3. UAC Operation 3.3. UAC Operation
A UAC conforming to this specification MUST include the sip.608 A UAC conforming to this specification MUST include the sip.608
feature capability tag in the INVITE request. feature capability indicator in the Feature-Caps header field of the
INVITE request.
Upon receiving a 608 response, UACs perform normal SIP processing for Upon receiving a 608 response, UACs perform normal SIP processing for
6xx responses. 6xx responses.
3.4. Legacy Interoperation 3.4. Legacy Interoperation
If the UAC indicates support for 608 and the intermediary issues a If the UAC indicates support for 608 and the intermediary issues a
608, life is good as the UAC will receive all the information it 608, life is good as the UAC will receive all the information it
needs to remediate an erroneous block by an intermediary. However, needs to remediate an erroneous block by an intermediary. However,
what if the UAC does not understand 608? For example, how can we what if the UAC does not understand 608? For example, how can we
skipping to change at page 9, line 46 skipping to change at page 9, line 47
conforms with this specification play an announcement in the media. conforms with this specification play an announcement in the media.
See Section 3.5 for requirements on the announcement. The simple See Section 3.5 for requirements on the announcement. The simple
rule is a network element that inserts the sip.608 feature capability rule is a network element that inserts the sip.608 feature capability
MUST be able to convey at a minimum how to contact the operator of MUST be able to convey at a minimum how to contact the operator of
the intermediary that rejected the call attempt. the intermediary that rejected the call attempt.
The degenerate case is the intermediary is the only element that The degenerate case is the intermediary is the only element that
understands the semantics of the 608 response code. Obviously, any understands the semantics of the 608 response code. Obviously, any
SIP device will understand that a 608 response code is a 6xx error. SIP device will understand that a 608 response code is a 6xx error.
However, there are no other elements in the call path that understand However, there are no other elements in the call path that understand
the meaning of the value of the Call-Info header. The intermediary the meaning of the value of the Call-Info header field. The
knows this is the case as the INVITE request will not have the intermediary knows this is the case as the INVITE request will not
sip.608 feature capability. In this case, one can consider the have the sip.608 feature capability. In this case, one can consider
intermediary to be the element 'inserting' a virtual sip.608 feature the intermediary to be the element 'inserting' a virtual sip.608
capability. If the caveats described in Section 3.5 and Section 6 do feature capability. If the caveats described in Section 3.5 and
not hold, the intermediary MUST play the announcement. Section 6 do not hold, the intermediary MUST play the announcement.
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]. [RFC6809].
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 forward the 608 response code message as the final element MUST forward 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 that only the network
that will consume (UAC) or play an announcement (media gateway, SBC, elements that will either consume (UAC) or play an announcement
or proxy) need understand the sip.608 feature capability. All other (media gateway, session border controller (SBC [RFC7092]), or proxy)
(existing) infrastructure can remain without modification, assuming need to understand the sip.608 feature capability. The rest of the
they are conformant to Section 16.6 of [RFC3261], specifically they infrastructure does not need to be modified, assuming that the other
will pass headers such as "Feature-Capability: sip.608" unmodified. network elements conform to Section 16.6 of [RFC3261], specifically
they will pass headers such as "Feature-Caps: *;+sip.608" unmodified.
3.5. Announcement Requirements 3.5. Announcement Requirements
There are a few requirements on the element that will be doing the There are a few requirements on the element that handles the
announcement for legacy interoperation. announcement for legacy interoperation.
As noted above, the element that inserts the sip.608 feature As noted above, the element that inserts the sip.608 feature
capability is responsible for conveying the information referenced by capability is responsible for conveying the information referenced by
the Call-Info header in the 608 response message. However, this the Call-Info header field in the 608 response message. However,
specification does not mandate the modality for conveying that this specification does not mandate how to convey that information.
information.
Let us take the case where a telecommunications service provider Let us take the case where a telecommunications service provider
controls the element inserting the sip.608 feature capability. It controls the element inserting the sip.608 feature capability. It
would be reasonable to expect the service provider would play an would be reasonable to expect the service provider would play an
announcement in the media path towards the UAC (caller). It is announcement in the media path towards the UAC (caller). It is
important to note the network element should be mindful of the media important to note the network element should be mindful of the media
type requested by the UAC as it formulates the announcement. For type requested by the UAC as it formulates the announcement. For
example, it would make sense for an INVITE that only indicated audio example, it would make sense for an INVITE that only indicated audio
codecs in the SDP [RFC4566] to result in an audio announcement. codecs in the SDP [RFC4566] to result in an audio announcement.
However, if the INVITE only indicated a real-time text codec and the However, if the INVITE only indicated a real-time text codec and the
skipping to change at page 11, line 17 skipping to change at page 11, line 20
4. Examples 4. Examples
These examples are not normative, do not include all protocol These examples are not normative, do not include all protocol
elements, and may have errors. Review the protocol documents for elements, and may have errors. Review the protocol documents for
actual syntax and semantics of the protocol elements. actual syntax and semantics of the protocol elements.
4.1. Full Exchange 4.1. Full Exchange
Given an INVITE (shamelessly taken from [SHAKEN]): Given an INVITE (shamelessly taken from [SHAKEN]):
INVITE sip:+12155551213@tel.example1.net SIP/2.0 INVITE sip:+12155550113@tel.one.example.net SIP/2.0
Max-Forwards: 69 Max-Forwards: 69
Contact: <sip:+12155551212@69.241.19.12:50207;rinstance=9da3088f36cc> Contact: <sip:+12155550112@2001:db8::12:50207;rinstance=9da3088f36cc>
To: <sip:+12155551213@tel.example1.net> To: <sip:+12155550113@tel.one.example.net>
From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40 From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155551212@tel.example2.net>, P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>,
<tel:+12155551212> <tel:+12155550112>
CSeq: 2 INVITE CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
MESSAGE, OPTIONS MESSAGE, OPTIONS
Content-Type: application/sdp Content-Type: application/sdp
Date: Tue, 16 Aug 2016 19:23:38 GMT Date: Tue, 16 Aug 2016 19:23:38 GMT
Feature-Caps: *;+sip.608 Feature-Caps: *;+sip.608
Identity: Identity:
eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1I
joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC joiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNvbWNhc3QubmV0L2V4YW1wbGUuY2VydC
J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI J9eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiI
xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6 xNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6
IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6n
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 IP6 2001:db8::177
c=IN IP4 192.0.2.177 c=IN IP6 2001:db8::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 2001:db8::177:60012;branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155551212@tel.example2.net>;tag=614bdb40 From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
To: <sip:+12155551213@tel.example1.net> To: <sip:+12155550113@tel.one.example.net>
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE CSeq: 2 INVITE
Call-Info: <https://block.example.net/complaint.json>;purpose=jwscard Call-Info: <https://block.example.net/complaint.json>;purpose=jwscard
The location https://block.example.net/complaint.json resolves to a The location https://block.example.net/complaint.json resolves to a
JWS. The JWS would be constructed as follows. JWS. The JWS would be constructed as follows.
The JWS header of this example jCard could be: The JWS header of this example jCard could be:
{ {"alg":"ES256"}, { {"alg":"ES256"},
skipping to change at page 13, line 46 skipping to change at page 13, line 46
. .
ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK
ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu
Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb
ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0
IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K
We use the following X.509 PKCS #8-encoded ECDSA private key, also We use the following X.509 PKCS #8-encoded ECDSA private key, also
shamelessly taken from [SHAKEN]), as an example key for signing the shamelessly taken from [SHAKEN]), as an example key for signing the
hash of the above text. Do NOT use this key in real life! It is for hash of the above text. Do NOT use this key in real life! It is for
exemplary purposes only. At the very least, we would strongly example purposes only. At the very least, we would strongly
recommend the key being encrypted at rest. recommend the key being encrypted at rest.
-----BEGIN PRIVATE KEY----- -----BEGIN PRIVATE KEY-----
MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgi7q2TZvN9VDFg8Vy
qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW qCP06bETrR2v8MRvr89rn4i+UAahRANCAAQWfaj1HUETpoNCrOtp9KA8o0V79IuW
ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh ARKt9C1cFPkyd3FBP4SeiNZxQhDrD0tdBHls3/wFe8++K2FrPyQF9vuh
-----END PRIVATE KEY----- -----END PRIVATE KEY-----
The resulting JWS, using the above key on the above object, renders The resulting JWS, using the above key on the above object, renders
the following ECDSA P-256 SHA-256 digital signature. the following ECDSA P-256 SHA-256 digital signature.
skipping to change at page 14, line 34 skipping to change at page 14, line 34
bImZuIiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICA bImZuIiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICA
gICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ gICBbImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ
0ZXh0IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICB 0ZXh0IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICB
dCn0K.MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5e dCn0K.MEUCIQCF2nv/eKvnGQNELZglQTpWbYtzbEf97xH4zKnkLx7S0QIgIl2f5e
hMOwjMTS+skjf1163ihH5+yIHQS3quklEt/9o= hMOwjMTS+skjf1163ihH5+yIHQS3quklEt/9o=
4.2. Web Site jCard 4.2. Web Site jCard
For an intermediary that provides a Web site for adjudication, the For an intermediary that provides a Web site for adjudication, the
jCard could contain the following. Note the calculation of the JWS 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 is not shown; the URI reference in the Call-Info header field would
the JWS of the signed jCard. be to the JWS of the signed jCard.
["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["url", {"type":"work"}, ["url", {"type":"work"},
"text", "https://blocker.example.net/adjudication-form"] "text", "https://blocker.example.net/adjudication-form"]
] ]
] ]
4.3. Multi-modal jCard 4.3. Multi-modal jCard
For an intermediary that provides a telephone number and a postal For an intermediary that provides a telephone number and a postal
address, the jCard could contain the following. Note the calculation address, the jCard could contain the following. Note the calculation
of the JWS is not shown; the URI reference in the Call-Info header of the JWS is not shown; the URI reference in the Call-Info header
would be to the JWS of the signed jCard. field would be to the JWS of the signed jCard.
["vcard", ["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["adr", {"type":"work"}, "text", ["adr", {"type":"work"}, "text",
["Argument Clinic", ["Argument Clinic",
"12 Main St","Anytown","AP","000000","Somecountry"] "12 Main St","Anytown","AP","000000","Somecountry"]
] ]
["tel", {"type":"work"}, "uri", "tel:+1-555-555-1212"] ["tel", {"type":"work"}, "uri", "tel:+1-555-555-0112"]
] ]
] ]
Note that it is up to the UAC to decide which jCard 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.
4.4. Legacy Interoperability 4.4. Legacy Interoperability
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 field for the INVITE. When the intermediary,
"Called Party Proxy" in the figure, rejects the call, it knows it can labeled "Called Party Proxy" in the figure, rejects the call, it
simply perform the processing described in this document. Since the knows it can simply perform the processing described in this
intermediary saw the sip.608 feature capability, it knows it does not document. Since the intermediary saw the sip.608 feature capability,
need to send any media describing whom to contact in the event of an it knows it does not need to send any media describing whom to
erroneous rejection. contact in the event of an erroneous rejection.
+---------+ +---------+
| Call | | Call |
|Analytics| |Analytics|
| Engine | | Engine |
+---------+ +---------+
^ | ^ |
| v | v
+---------+ +---------+
| Called | +-----+ +-----+ +---+ +-----+ +---+ | Called | +-----+ +-----+ +---+ +-----+ +---+
skipping to change at page 18, line 9 skipping to change at page 18, line 9
Claim Description: jCard data Claim Description: jCard data
Change Controller: IESG Change Controller: IESG
Reference: [RFCXXXX], [RFC7095] Reference: [RFCXXXX], [RFC7095]
5.4. Call-Info Purpose 5.4. Call-Info Purpose
This document defines the new predefined value "jwscard" for the This document defines the new predefined value "jwscard" for the
"purpose" header field parameter of the Call-Info header field. This "purpose" header field parameter of the Call-Info header field. This
modifies the registry header field parameters and parameter values by modifies the "Header Field Parameters and Parameter Values"
adding this RFC as a reference to the line for the header field subregistry of the "Session Initiation Protocol (SIP) Parameters"
"Call-Info" and parameter name "purpose": registry by adding this RFC as a reference to the line for the header
field "Call-Info" and parameter name "purpose":
Header Field: Call-Info Header Field: Call-Info
Parameter Name: purpose Parameter Name: purpose
Predefined Values: Yes Predefined Values: Yes
Reference: [RFCXXXX] Reference: [RFCXXXX]
6. Security Considerations 6. Security Considerations
skipping to change at page 18, line 37 skipping to change at page 18, line 38
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 in the Call- more significant risk, is that by providing a contact in the Call-
Info field, the intermediary may be giving the malicious caller a Info field, the intermediary may be giving the malicious caller 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 flood a proxy that supports the
feature capability in a flood of INVITE requests, direct those sip.608 feature with INVITE requests that lack the sip.608 feature
requests to proxies known to insert the sip.608 feature, and direct capability in order to direct the SDP to a victim's device. Because
the SDP to a victim device. Because the mechanism described here can the mechanism described here can result in an audio file being sent
result in an audio file being sent to the target of the Contact to the target of the Contact header field, an attacker could use the
header, an attacker could use the mechanism described by this 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 devices that
remediation for this is for devices that insert a sip.608 feature insert a sip.608 feature capability only transmit media to what is
capability only transmit media to what is highly likely to be the highly likely to be the actual source of the call attempt. A method
actual source of the call attempt. A method for this is to only play for this is to only play media in response to an INVITE that is
media in response to an INVITE that is signed and passed validation signed and passed validation by STIR [RFC8224].
by STIR [RFC8224].
Yet another risk is a malicious entity or the intermediary itself can Yet another risk is a malicious entity or the intermediary itself can
generate a malicious 608 response with a jCard referring to a generate a malicious 608 response with a jCard referring to a
malicious agent. For example, the recipient of a 608 may receive a malicious agent. For example, the recipient of a 608 may receive a
TEL URI in the vCard. When the recipient calls that address, the TEL URI in the vCard. When the recipient calls that address, the
malicious agent could ask for personally identifying information. malicious agent could ask for personally identifying information.
However, instead of using that information to verify the recipient's However, instead of using that information to verify the recipient's
identity, they are pharming the information for nefarious ends. As identity, they are phishing the information for nefarious ends. As
such, we strongly recommend the recipient validates to whom they are such, we strongly recommend the recipient validates to whom they are
communicating with if asking to adjudicate an erroneously rejected communicating with if asking to adjudicate an erroneously rejected
call attempt. Since we may also be concerned about intermediate call attempt. Since we may also be concerned about intermediate
nodes modifying contact information, we can address both of these nodes modifying contact information, we can address both of these
issues with a single solution. The remediation is to require the issues with a single solution. The remediation is to require the
intermediary to sign the jCard. Signing the jCard provides integrity intermediary to sign the jCard. Signing the jCard provides integrity
protection. In addition, one can imagine mechanisms such as used by protection. In addition, one can imagine mechanisms such as used by
SHAKEN [SHAKEN] to use signing certificate issuance as a mechanism SHAKEN [SHAKEN] to use signing certificate issuance as a mechanism
for traceback to the entity issuing the jCard, for example tying the 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 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 initial SIP request, as if the intermediary was vouching for the From
field of a SIP request with that identity. field of a SIP request with that identity.
Since the decision of whether to include Call-Info in the 608 Since the decision of whether to include Call-Info in the 608
response is a matter of policy, one thing to consider is whether a response is a matter of policy, one thing to consider is whether a
legitimate caller can ascertain whom to contact without such legitimate caller can ascertain whom to contact without such
information being included in the 608. For example, in some information being included in the 608. For example, in some
jurisdictions, if the terminating service provider is the jurisdictions, if the terminating service provider is the
intermediary, the caller can lookup who the terminating service intermediary, the caller can look up who the terminating service
provider is based on the routing information for the dialled number. provider is based on the routing information for the dialed number.
As such, the Call-Info jCard could be redundant information. As such, the Call-Info jCard could be redundant information.
However, the factors going into a particular service provider's or However, the factors going into a particular service provider's or
jourisdiction's choice of whether or not to include Call-Info is jurisdiction's choice of whether or not to include Call-Info is
outside the scope of this document. outside the scope of this document.
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 jCard attack. Finally, Christer addition, Tolga came up with the jCard attack. Finally, Christer
Holmberg as always provided a close reading and caught a SIP feature Holmberg as always provided a close reading and fixed a SIP feature
capability bug. capability bug found by Yehoshua Gev.
Finally, Bhavik Nagda provided clarifying edits as well and more Finally, Bhavik Nagda provided clarifying edits as well and more
especially wrote and tested an implementation of the 608 response especially wrote and tested an implementation of the 608 response
code in Kamailio. Code is available at <https://github.com/ code in Kamailio. Code is available at <https://github.com/
nagdab/608_Implementation> . nagdab/608_Implementation> .
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 21, line 9 skipping to change at page 21, line 9
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[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>. https://apps.dtic.mil/docs/citations/ADA045772>.
[ITU.E.180.1998] [ITU.E.180.1998]
International Telecommunications Union, "Technical International Telecommunications Union, "Technical
characteristics of tones for the telephone service", characteristics of tones for the telephone service",
ITU Recommendation E.180/Q.35, March 1998. ITU Recommendation E.180/Q.35, March 1998.
[RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic [RFC4240] Burger, E., Ed., Van Dyke, J., and A. Spitzer, "Basic
Network Media Services with SIP", RFC 4240, Network Media Services with SIP", RFC 4240,
DOI 10.17487/RFC4240, December 2005, DOI 10.17487/RFC4240, December 2005,
<https://www.rfc-editor.org/info/rfc4240>. <https://www.rfc-editor.org/info/rfc4240>.
skipping to change at page 21, line 34 skipping to change at page 21, line 34
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, [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
DOI 10.17487/RFC6350, August 2011, DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>. <https://www.rfc-editor.org/info/rfc6350>.
[RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session
Initiation Protocol (SIP) Back-to-Back User Agents",
RFC 7092, DOI 10.17487/RFC7092, December 2013,
<https://www.rfc-editor.org/info/rfc7092>.
[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,
 End of changes. 36 change blocks. 
104 lines changed or deleted 113 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/