draft-ietf-sipcore-rejected-06.txt   draft-ietf-sipcore-rejected-07.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 9, 2019 Massachusetts Institute of Technology Expires: October 25, 2019 Massachusetts Institute of Technology
April 7, 2019 April 23, 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-06 draft-ietf-sipcore-rejected-07
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. No one will deliver, and thus no one
6xx code, the caller will be aware that future attempts to contact will answer, the call. As a 6xx code, the caller will be aware that
the same UAS will likely fail. The present use case driving the need future attempts to contact the same User Agent Server will likely
for the 608 response code is when the intermediary is an analytics fail. The initial use case driving the need for the 608 response
engine. In this case, the rejection is by a machine or other code is when the intermediary is an analytics engine. In this case,
process. This contrasts with the 607 (Unwanted) SIP response code, the rejection is by a machine or other process. This contrasts with
which a human at the target UAS indicated the call was not wanted. the 607 (Unwanted) SIP response code, which a human at the target
In some jurisdictions this distinction is important. This document User Agent Server indicated the user did not want the call. In some
also defines the use of the Call-Info header field in 608 responses jurisdictions this distinction is important. This document also
to enable rejected callers to contact entities that blocked their defines the use of the Call-Info header field in 608 responses to
calls in error. This provides a remediation mechanism for legal enable rejected callers to contact entities that blocked their calls
callers that find their calls blocked. in error. This provides a remediation mechanism for legal 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 9, 2019. This Internet-Draft will expire on October 25, 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 2, line 26 skipping to change at page 2, line 26
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 8 3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 8
3.2. jCard Construction . . . . . . . . . . . . . . . . . . . 8 3.2. JWS Construction . . . . . . . . . . . . . . . . . . . . 9
3.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 8 3.2.2. JWT Payload . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 9 3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 9
3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 9 3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 9 3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 10
3.5. Announcement Requirements . . . . . . . . . . . . . . . . 10 3.5. Announcement Requirements . . . . . . . . . . . . . . . . 11
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 14 4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 15
4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 15 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 16
4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 15 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 17 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 18
5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 17 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 18
5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 17 5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 19
5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 18 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 20 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
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 the cryptographic signing and attestation, respectively, of address the 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
caller identity. caller identity.
This document describes a new SIP response code, 608, which allows This document describes a new SIP response code, 608, which allows
calling parties to learn that an intermediary rejected their call. calling parties to learn that an intermediary rejected their call.
As described below, we need a distinct indicator to differentiate As described below, we need a distinct indicator to differentiate
between a user rejection and an intermediary's rejection of a call. between a user rejection and an intermediary's rejection of a call.
In some jurisdictions, calls, even if unwanted by the user, may not In some jurisdictions, service providers may not block calls, even if
be blocked unless there is an explicit user request. Moreover, users unwanted by the user, unless there is an explicit user request.
may misidentify the nature of a caller. Moreover, users may misidentify the nature of a caller.
For example, a legitimate caller may call a user who finds the call For example, a legitimate caller may call a user who finds the call
to be unwanted. However, instead of marking the call as unwanted, to be unwanted. However, instead of marking the call as unwanted,
the user may mark the call as illegal. With that information, an the user may mark the call as illegal. With that information, an
analytics engine may determine that all calls from that source should analytics engine may determine to block all calls from that source.
be blocked. However, in some jurisdictions blocking calls from that However, in some jurisdictions blocking calls from that source for
source for other users may not be legal. Likewise, one can envision other users may not be legal. Likewise, one can envision
jurisdictions that allow an operator to block such calls, but only if jurisdictions that allow an operator to block such calls, but only if
there is a remediation mechanism in place to address false positives. there is a remediation mechanism in place to address false positives.
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 SIP User Agent blocked calls. Specifically, this code informs the SIP User Agent
Client (UAC) that an intermediary blocked the call and provides a Client (UAC) that an intermediary blocked the call and provides a
redress mechanism that allows callers to contact the operator of the redress mechanism that allows callers to contact the operator of the
intermediary. 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 show 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 User Agent Server (UAS)
was unwanted. As RFC8197 explains, not only does the called party indicates the call was unwanted. As [RFC8197] explains, not only
desire to reject that call, they can let their proxy know that they does the called party desire to reject that call, they can let their
consider future calls from that source unwanted. Upon receipt of the proxy know that they consider future calls from that source unwanted.
607 response from the UAS, the proxy may send call information to a Upon receipt of the 607 response from the UAS, the proxy may send
call analytics engine. For various reasons described in RFC8197, if call information to a call analytics engine. For various reasons
a network operator receives multiple reports of unwanted calls, that described in [RFC8197], if a network operator receives multiple
may indicate that the entity placing the calls is likely to be a reports of unwanted calls, that may indicate that the entity placing
source of unwanted calls for many people. As such, other customers the calls is likely to be a source of unwanted calls for many people.
of the service provider may want the service provider to As such, other customers of the service provider may want the service
automatically reject calls on their behalf. provider to automatically reject calls on their behalf.
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 User Agent Client (UAC), the calling UAC or
will also learn the user is not interested in receiving calls from intervening proxies will also learn the user is not interested in
that sender. 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 5, line 45 skipping to change at page 5, line 45
^ | (likely not SIP) ^ | (likely not SIP)
| v | v
+-----------+ +-----------+
+-----+ 608 | Called | +-----+ +-----+ 608 | Called | +-----+
| 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 consider 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 that network elements rejected a call. The problem here is that network elements
downstream from the intermediary might interpret the 607 as coming downstream from the intermediary might interpret the 607 as coming
from a user (human) that has marked the call as unwanted, as opposed from a user (human) that has marked the call as unwanted, as opposed
to coming from an algorithm using statistics or machine learning to to coming from an algorithm using statistics or machine learning to
reject the call. An algorithm can be vulnerable to the base rate reject the call. An algorithm can be vulnerable to an algorithm
fallacy base rate fallacy [BaseRate] algorithm rejecting the call. subject to the base rate fallacy [BaseRate] rejecting the call. In
In other words, those downstream entities should not rely on another other words, those downstream entities should not rely on another
entity 'deciding' the call is unwanted. By distinguishing between a entity 'deciding' the call is unwanted. By distinguishing between a
(human) user rejection and an intermediary engine's statistical (human) user rejection and an intermediary engine's statistical
rejection, a downstream network element that sees a 607 response code rejection, a downstream network element that sees a 607 response code
can weight it as a human rejection in its call analytics. can weigh it as a human rejection in its call analytics, versus
deciding whether to consider a 608 at all, and if so, weighing it
appropriately.
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 intermediaries block 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.
One might ask why we cannot use the same mechanism an analytics Why do we not use the same mechanism an analytics service provider
service provider offers their customers that lets them correct a call offers their customers? Specifically, why not have the analytics
blocked in error? The reason is while there is an existing service provider allow the called party to correct a call blocked in
relationship between the customer (called party) and the analytics error? The reason is while there is an existing relationship between
service provider, it is unlikely there is a relationship between the the customer (called party) and the analytics service provider, it is
caller and the analytics service provider. Moreover, there are unlikely there is a relationship between the caller and the analytics
numerous call blocking providers in the ecosystem. As such, we need service provider. Moreover, there are numerous call blocking
a mechanism for indicating an intermediary rejected a call that also providers in the ecosystem. As such, we need a mechanism for
provides contact information for the operator of that intermediary, indicating an intermediary rejected a call that also provides contact
without exposing the target user's contact information. information for the operator of that intermediary, 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 SIP protocol
mechanisms for specifying the redress mechanism. In the Call-Info mechanisms for specifying the redress mechanism. In the Call-Info
header passed back to the UAC, we send additional information header passed back to the UAC, we send additional information
specifying a redress address. We choose to encode the redress specifying a redress address. We choose to encode the redress
address using jCard [RFC7095]. Conveniently, we use jCard rather address using jCard [RFC7095]. As we will see later in this
than vCard [RFC6350] as we have a standard marshaling mechanism for document, this information needs to have its own, application-layer
creating a canonical representation of a JSON [RFC8259] object, such integrity protection. As such, we use jCard rather than vCard
as a jCard, and a standard presentation format for such an object, [RFC6350] as we have a marshaling mechanism for creating a JavaScript
namely JWS [RFC7515]. The SIP community is familiar with this Object Notation (JSON) [RFC8259] object, such as a jCard, and a
standard integrity format for such an object, namely JSON Web
Signature (JWS) [RFC7515]. The SIP community is familiar with this
concept as it is 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 Integrity protecting the jCard with a cryptographic signature might
essential to preventing potential network attacks. Suppose, for seem unnecessary at first, but it is essential to preventing
example, that the redress address was simply passed as a header potential network attacks. Suppose, for example, that one simply
value. One can imagine an adverse agent that maliciously spoofs a passes the redress address as a header field value. One can imagine
608 response with the same redress address to a large number of an adverse agent that maliciously spoofs a 608 response with the same
active callers, who may then all send redress requests to the redress address to many active callers, who may then all send redress
specified address (the basis for a denial-of-service attack). The requests to the specified address (the basis for a denial-of-service
process would occur as follows: (1) a malicious agent senses INVITE attack). The process would occur as follows: (1) a malicious agent
requests from a variety UACs and (2) spoofs 608 responses with an senses INVITE requests from a variety UACs and (2) spoofs 608
unsigned redress address before the intended receivers can respond, responses with an unsigned redress address before the intended
causing (3) the UACs to all contact the redress address at once. The receivers can respond, causing (3) the UACs to all contact the
jCard encoding allows the UAC to verify the blocking intermediary's redress address at once. The jCard encoding allows the UAC to verify
identity before contacting the redress address. This guards against the blocking intermediary's identity before contacting the redress
a malicious agent spoofing 608 responses, preventing the denial-of- address. This guards against a malicious agent spoofing 608
service attack. Thus, if the jCard address is unreachable or responses, preventing the denial-of-service attack. Thus, if the
undecipherable, either (1) a malicious agent is lying about the jCard jCard address is unreachable or undecipherable, either (1) a
or (2) the redress mechanism is misconfigured. malicious agent is lying about the jCard or (2) the redress mechanism
is misconfigured.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Operation 3. Protocol Operation
skipping to change at page 8, line 21 skipping to change at page 8, line 37
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 field 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 field in the response. Call-Info header field in the response.
If there is a Call-Info header field, it MUST have the 'purpose' If there is a Call-Info header field, it MUST have the 'purpose'
parameter of 'jwscard'. The value of the Call-Info header field MUST parameter of 'jwscard'. The value of the Call-Info header field MUST
refer to a valid JWS [RFC7515] encoding of a jCard [RFC7095] object. refer to a valid JSON Web Signature (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] 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. JWS Construction
The intermediary constructs the JWS as follows. The intermediary constructs the JWS of the jCard as follows.
3.2.1. JOSE Header 3.2.1. JOSE Header
The JOSE header MUST include the typ, alg, and x5u parameters from The Javascript Object Signing and Encryption (JOSE) header MUST
JWS [RFC7515]. The typ parameter MUST have the value "vcard+json". include the typ, alg, and x5u parameters from JWS [RFC7515]. The typ
Implementations MUST support ES256 as JWA [RFC7518] defines it, and parameter MUST have the value "vcard+json". Implementations MUST
support ES256 as JSON Web Algorithms (JWA [RFC7518]) defines it, and
MAY support other registered signature algorithms. Finally, the x5u MAY support other registered signature algorithms. Finally, the x5u
parameter MUST be a URI that resolves to the public key certificate parameter MUST be a URI that resolves to the public key certificate
corresponding to the key used to digitally sign the JWS. corresponding to the key used to digitally sign the JWS.
3.2.2. JWT Payload 3.2.2. JWT Payload
The payload contains two JSON values. The first JWT claim that MUST The payload contains two JSON values. The first JSON Web Token (JWT)
be present is the iat (issued at) claim [RFC7519]. The "iat" MUST be claim that MUST be present is the iat (issued at) claim [RFC7519].
set to the date and time of the issuance of the 608 response. This The "iat" MUST be set to the date and time of the issuance of the 608
mandatory component protects the response from replay attacks. response. This mandatory component protects the response from replay
attacks.
The second JWT claim that MUST be present is the jcard claim. The second JWT claim that MUST be present is the jcard claim.
Section 5.3 describes the registration. In the construction of the Section 5.3 describes the registration. In the construction of the
jcard claim, the "jcard" MUST include at least one of the URL, EMAIL, jcard claim, the "jcard" MUST include at least one of the URL, EMAIL,
TEL, or ADR properties. UACs supporting this specification MUST be TEL, or ADR properties. UACs supporting this specification MUST be
prepared to receive a full jCard. Call originators (at the UAC) can prepared to receive a full jCard. Call originators (at the UAC) can
use the information returned by the jCard to contact the intermediary use the information returned by the jCard to contact the intermediary
that rejected the call to appeal the intermediary's blocking of the that rejected the call to appeal the intermediary's blocking of the
call attempt. What the intermediary does if the blocked caller call attempt. What the intermediary does if the blocked caller
contacts the intermediary is outside the scope of this document. contacts the intermediary is outside the scope of this document.
skipping to change at page 9, line 27 skipping to change at page 10, line 5
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 indicator in the Feature-Caps header field of the feature capability indicator in the Feature-Caps header field of the
INVITE request. 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.
As for the disposition of the jCard itself, the UAC MUST check the
"iat" claim in the JWT. As noted in Section 3.2.3, we are concerned
about replay attacks. As such, the UAC MUST reject jCards that come
with an expired "iat". The definition of "expired" is a matter of
local policy. A reasonable value would be on the order of a minute
due to clock drift and the possibility of the playing of an audio
announcement before the delivery of the 608 response.
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
support callers from a legacy, non-SIP public switched network support callers from a legacy, non-SIP public switched network
connecting to the SIP network via a media gateway? connecting to the SIP network via a media gateway?
We address this situation by having the first network element that We address this situation by having the first network element that
skipping to change at page 10, line 21 skipping to change at page 11, line 5
[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 that only the network One aspect of using a feature capability is that only the network
elements that will either consume (UAC) or play an announcement elements that will either consume (UAC) or play an announcement
(media gateway, session border controller (SBC [RFC7092]), or proxy) (media gateway, session border controller (SBC [RFC7092]), or proxy)
need to understand the sip.608 feature capability. The rest of the need to understand the sip.608 feature capability. If the other
infrastructure does not need to be modified, assuming that the other network elements conform to Section 16.6 of [RFC3261], they will pass
network elements conform to Section 16.6 of [RFC3261], specifically header fields such as "Feature-Caps: *;+sip.608" unmodified and
they will pass headers such as "Feature-Caps: *;+sip.608" unmodified. without need for upgrade.
Because the ultimate disposition of the call attempt will be a
600-class response, the network element conveying the announcement in
the legacy direction MUST use the 183 Session Progress response to
establish the media session. Because of the small chance the UAC is
an extremely old legacy device and is using UDP, the UAC MUST include
support for 100Rel [RFC3262] in its INVITE and the network element
conveying the announcement MUST Require 100Rel in the 183 and the UAC
MUST issue a PRACK to which the network element MUST respond 200 OK
PRACK.
3.5. Announcement Requirements 3.5. Announcement Requirements
There are a few requirements on the element that handles 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 field in the 608 response message. However, the Call-Info header field in the 608 response message. However,
this specification does not mandate how to convey that information. this specification does not mandate how to convey that 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 Session Description Protocol (SDP) [RFC4566] to result
However, if the INVITE only indicated a real-time text codec and the in an audio announcement. However, if the INVITE only indicated a
network element is able to render the information in the requested real-time text codec and the network element can render the
media format, the network element MUST send the information in a text information in the requested media format, the network element MUST
format, not an audio format. send the information in a text format, not an audio format.
It is also possible for the network element inserting the sip.608 It is also possible for the network element inserting the sip.608
feature capability to be under the control of the same entity that feature capability to be under the control of the same entity that
controls the UAC. For example, a large call center might have legacy controls the UAC. For example, a large call center might have legacy
UACs, but have a modern outbound calling proxy that understands the UACs, but have a modern outbound calling proxy that understands the
full semantics of the 608 response code. In this case, it is enough full semantics of the 608 response code. In this case, it is enough
for the outbound calling proxy to digest the Call-Info information for the outbound calling proxy to digest the Call-Info information
and handle the information digitally, rather than 'transcoding' the and handle the information digitally, rather than 'transcoding' the
Call-Info information for presentation to the caller. Call-Info information for presentation to the caller.
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:+12155550113@tel.one.example.net SIP/2.0 INVITE sip:+12155550113@tel.one.example.net SIP/2.0
Max-Forwards: 69 Max-Forwards: 69
Contact: <sip:+12155550112@2001:db8::12:50207;rinstance=9da3088f36cc> Contact: <sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f36cc>
To: <sip:+12155550113@tel.one.example.net> To: <sip:+12155550113@tel.one.example.net>
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40 From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>, P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>,
<tel:+12155550112> <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 IP6 2001:db8::177 o=- 13103070023943130 1 IN IP6 2001:db8::177
c=IN IP6 2001:db8::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 2001:db8::177:60012;branch=z9hG4bK-524287-1 Via: SIP/2.0/UDP [2001:db8::177:60012;branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40 From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
To: <sip:+12155550113@tel.one.example.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. One would construct the JWS would as follows.
The JWS header of this example jCard could be: The JWS header of this example jCard could be:
{ {"alg":"ES256"}, { {"alg":"ES256"},
{"typ":"vcard+json"}, {"typ":"vcard+json"},
{"x5u":"https://certs.example.net/reject_key.cer"} } {"x5u":"https://certs.example.net/reject_key.cer"} }
Now, let us construct a minimal jCard. For this example, the jCard Now, let us construct a minimal jCard. For this example, the jCard
refers the caller to an email address, bitbucket@blocker.example.net: refers the caller to an email address, bitbucket@blocker.example.net:
skipping to change at page 12, line 48 skipping to change at page 13, line 48
"jcard":["vcard", "jcard":["vcard",
[ [
["version", {}, "text", "4.0"], ["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], ["fn", {}, "text", "Robocall Adjudication"],
["email", {"type":"work"}, ["email", {"type":"work"},
"text", "bitbucket@blocker.example.net"] "text", "bitbucket@blocker.example.net"]
] ]
] ]
} }
In order to calculate the signature, we need to encode the JOSE To calculate the signature, we need to encode the JSON Object Signing
header and JWT into base64. As an implementation note, one can trim and Encryption (JOSE) header and JWT into base64url. As an
whitespace in the JSON objects to save a few bytes. UACs MUST be implementation note, one can trim whitespace in the JSON objects to
prepared to receive pretty printed, compact, or bizarrely formatted save a few bytes. UACs MUST be prepared to receive pretty-printed,
JSON. For the purposes of this example, we leave the objects with compact, or bizarrely formatted JSON. For the purposes of this
pretty whitespace. Speaking of pretty vs. machine formatting, these example, we leave the objects with pretty whitespace. Speaking of
examples have line breaks in the base64 encodings for ease of pretty vs. machine formatting, these examples have line breaks in the
publication in the RFC format. The specification of base64 allows base64url encodings for ease of publication in the RFC format. The
for these line breaks and the decoded text works just fine. However, specification of base64url allows for these line breaks and the
those extra line break octets would affect the calculation of the decoded text works just fine. However, those extra line break octets
signature. As such, implementations MUST NOT insert line breaks into would affect the calculation of the signature. As such,
the base64 encodings of the JOSE header or JWT. This also means UACs implementations MUST NOT insert line breaks into the base64url
MUST be prepared to receive arbitrarily long octet streams from the encodings of the JOSE header or JWT. This also means UACs MUST be
URI referenced by the Call-Info SIP header. prepared to receive arbitrarily long octet streams from the URI
referenced by the Call-Info SIP header.
base64 of JOSE header: base64url of JOSE header:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo= fQo=
base64 of JWT: base64url of JWT:
ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK ewogICJpYXQiOjE1NDYwMDg2OTgsCiAgImpjYXJkIjpbInZjYXJkIiwKICAgIFsK
ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu ICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICBbImZu
Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb Iiwge30sICJ0ZXh0IiwgIlJvYm9jYWxsIEFkanVkaWNhdGlvbiJdLAogICAgICBb
ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0 ImVtYWlsIiwgeyJ0eXBlIjoid29yayJ9LCAKICAgICAgICAgICAgICAgICJ0ZXh0
IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K IiwgImJpdGJ1Y2tldEBibG9ja2VyLmV4YW1wbGUubmV0Il0KICAgIF0KICBdCn0K
In this case, the object to be signed (remembering this is just a In this case, the object to sign (remembering this is just a single,
single, long line; the line breaks are for ease of review but do not long line; the line breaks are for ease of review but do not appear
appear in the actual text being signed is as follows: in the actual object) is as follows:
eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4 eyB7ImFsZyI6IkVTMjU2In0sCiAgeyJ0eXAiOiJ2Y2FyZCtqc29uIn0sCiAgeyJ4
NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g NXUiOiJodHRwczovL2NlcnRzLmV4YW1wbGUubmV0L3JlamVjdF9rZXkuY2VyIn0g
fQo= fQo=
. .
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
example 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 encrypting the key 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 33 skipping to change at page 15, line 33
gIFsKICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICB gIFsKICAgICAgWyJ2ZXJzaW9uIiwge30sICJ0ZXh0IiwgIjQuMCJdLAogICAgICB
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 we do not show the
is not shown; the URI reference in the Call-Info header field would calculation of the JWS; the URI reference in the Call-Info header
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"],
["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 we do not show
of the JWS is not shown; the URI reference in the Call-Info header the calculation of the JWS; the URI reference in the Call-Info header
field 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"]
] ]
skipping to change at page 15, line 32 skipping to change at page 16, line 32
] ]
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], the SBC can insert "*;+sip.608" into the
Feature-Caps header field for the INVITE. When the intermediary, Feature-Caps header field for the INVITE. When the intermediary,
labeled "Called Party Proxy" in the figure, rejects the call, it labeled "Called Party Proxy" in the figure, rejects the call, it
knows it can simply perform the processing described in this knows it can simply perform the processing described in this
document. Since the intermediary saw the sip.608 feature capability, document. Since the intermediary saw the sip.608 feature capability,
it knows it does not need to send any media describing whom to it knows it does not need to send any media describing whom to
contact in the event of an erroneous rejection. contact in the event of an erroneous rejection.
+---------+ +---------+
| Call | | Call |
|Analytics| |Analytics|
| Engine | | Engine |
+---------+ +--+--+---+
^ | ^ |
| v | |
+---------+ | v
| Called | +-----+ +-----+ +---+ +-----+ +---+ +-+--+-+
| Party | <---|Proxy| <---|Proxy| <---|SBC| <---|Proxy| <---|UAC| +---+ +-----+ +---+ +-----+ +-----+ |Called|
| Proxy | +-----+ +-----+ +---+ +-----+ +---+ |UAC+--->+Proxy+--->+SBC+--->+Proxy+--->+Proxy+--->+Party |
+---------+ | | +---+ +-----+ +---+ +-----+ +-----+ |Proxy |
| | INVITE | | +------+
| INVITE |<--------------------| | INVITE | |
|<-----------------------------------| | |------------------>| |
| Feature-Caps: *;+sip.608 | | | | INVITE |
| | | | |------------------------------>|
| 608 Rejected | | | | Feature-Caps: *;+sip.608 |
|----------------------------------->| 183 | | | |
| Call-Info: <...> |-------------------->| | | 608 Rejected |
| [path for Call-Info elided | SDP for media | | |<------------------------------|
| for illustration purposes] | | | 183 | Call-Info: <...> |
| |=== Announcement ===>| |<------------------| [path for Call-Info elided |
| | | | SDP for media | for illustration purposes]|
| | 608 | | | |
| |-------------------->| | PRACK | |
| | Call-Info: <...> | |------------------>| |
| | |
| 200 OK PRACK | |
|<------------------| |
| | |
|<== Announcement ==| |
| | |
| 608 Rejected | |
|<------------------| |
| Call-Info: <...> | |
| | |
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. Since this is a
potentially long transaction and there is a chance the UAC is using
an unreliable transport protocol, the UAC will have indicated support
for provisional responses, the SBC will indicate it requires a PRACK
from the UAC in the 183 response, the UAC will provide the PRACK, and
the SBC will acknowledge receipt of the PRACK before playing the
announcement.
As an example, the SBC could extract the FN and TEL jCard 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
skipping to change at page 18, line 24 skipping to change at page 19, line 38
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
Intermediary operators need to be mindful of whom they are sending Intermediary operators need to be mindful to whom they are sending
the 608 response. There is a risk that a truly malicious caller is the 608 response. The intermediary could be rejecting a truly
being rejected. This raises two issues. The first is the caller, malicious caller. This raises two issues. The first is the caller,
now alerted that the call is being automatically rejected, may change now alerted an intermediary is automatically rejecting their call
their call behavior to defeat call blocking systems. The second, and attempts, may change their call behavior to defeat call blocking
more significant risk, is that by providing a contact in the Call- systems. The second, and more significant risk, is that by providing
Info field, the intermediary may be giving the malicious caller a a contact in the Call-Info header field, the intermediary may be
vector for attack. In other words, the intermediary will be giving the malicious caller a vector for attack. In other words, the
publishing an address that a malicious actor may use to launch an intermediary will be publishing an address that a malicious actor may
attack on the intermediary. Because of this, intermediary operators use to launch an attack on the intermediary. Because of this,
may wish to configure their response to only include a Call-Info intermediary operators may wish to configure their response to only
field for INVITE or other initiating methods that are signed and pass include a Call-Info header field for INVITE or other signed
validation by STIR [RFC8224]. initiating methods and that pass validation by STIR [RFC8224].
Another risk is for an attacker to flood a proxy that supports the Another risk is for an attacker to flood a proxy that supports the
sip.608 feature with INVITE requests that lack the sip.608 feature sip.608 feature with INVITE requests that lack the sip.608 feature
capability in order to direct the SDP to a victim's device. Because capability to direct the SDP to a victim's device. Because the
the mechanism described here can result in an audio file being sent mechanism described here can result in sending an audio file to the
to the target of the Contact header field, an attacker could use the target of the SDP, an attacker could use the mechanism described by
mechanism described by this document as an amplification attack, this document as an amplification attack, given a SIP INVITE can be
given a SIP INVITE can be under 1 kilobyte and an audio file can be under 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 a STIR [RFC8224]-signed INVITE that passes
signed and passed validation by STIR [RFC8224]. validation. Beyond requiring a valid STIR signature on the INVITE,
the intermediary can also use remediation procedures such as doing
the connectivity checks specified by Interactive Connectivity
Establishment [RFC8445]. Presumably if the target did not request
the media, the check will fail.
Yet another risk is a malicious entity or the intermediary itself can Yet another risk is a malicious intermediary that generates a
generate a malicious 608 response with a jCard referring to a malicious 608 response with a jCard referring to a malicious agent.
malicious agent. For example, the recipient of a 608 may receive a For example, the recipient of a 608 may receive a TEL URI in the
TEL URI in the vCard. When the recipient calls that address, the vCard. When the recipient calls that address, the malicious agent
malicious agent could ask for personally identifying information. could ask for personally identifying information. However, instead
However, instead of using that information to verify the recipient's of using that information to verify the recipient's identity, they
identity, they are phishing the information for nefarious ends. As are phishing the information for nefarious ends. As such, we
such, we strongly recommend the recipient validates to whom they are 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 issues with
issues with a single solution. The remediation is to require the a single solution. The remediation is to require the intermediary to
intermediary to sign the jCard. Signing the jCard provides integrity sign the jCard. Signing the jCard provides integrity protection. In
protection. In addition, one can imagine mechanisms such as used by addition, one can imagine mechanisms such as used by SHAKEN [SHAKEN]
SHAKEN [SHAKEN] to use signing certificate issuance as a mechanism to use signing certificate issuance as a mechanism for traceback to
for traceback to the entity issuing the jCard, for example tying the the entity issuing the jCard, for example tying the identity of the
identity of the subject of the certificate to the To field of the subject of the certificate to the To header field of the initial SIP
initial SIP request, as if the intermediary was vouching for the From request, as if the intermediary was vouching for the From header
field of a SIP request with that identity. field of a SIP request with that identity. Note that we are only
protecting against a malicious intermediary and not a hidden
intermediary attack (formerly known as a "man in the middle attack").
As such, we only need to ensure the signature is fresh, which is why
we include "iat". For most implementations, we assume that the
intermediary has a single set of contact points and will generate the
jCard on demand. As such, there is no need to directly correlate
HTTPS fetches to specific calls. However, since the intermediary is
in control of the jCard and Call-Info response, an intermediary may
choose to encode per-call information in the URI returned in a given
608 response. However, if the intermediary does go that route, the
intermediary MUST use a non-deterministic reference mechanism and be
prepared to return dummy responses so that attackers attempting to
glean call metadata by guessing calls will not get any actionable
information from the HTTPS GET.
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 including
information being included in the 608. For example, in some such information in the 608. For example, in some jurisdictions, if
jurisdictions, if the terminating service provider is the only the terminating service provider can be the intermediary, the
intermediary, the caller can look up who the terminating service caller can look up who the terminating service provider is based on
provider is based on the routing information for the dialed number. the routing information for the dialed number. As such, the Call-
As such, the Call-Info jCard could be redundant information. Info jCard could be redundant information. However, the factors
However, the factors going into a particular service provider's or going into a particular service provider's or jurisdiction's choice
jurisdiction's choice of whether or not to include Call-Info is of whether to include Call-Info is outside the scope of this
outside the scope of this document. 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 fixed a SIP feature Holmberg as always provided a close reading and fixed a SIP feature
capability bug found by Yehoshua Gev. capability bug found by Yehoshua Gev.
Of course, we appreciated the close read and five pages of comments
from our estimable Area Director, Adam Roach.
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
[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>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
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>.
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
Provisional Responses in Session Initiation Protocol
(SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002,
<https://www.rfc-editor.org/info/rfc3262>.
[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>.
[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>.
skipping to change at page 22, line 10 skipping to change at page 24, line 5
"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 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive
Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", RFC 8445,
DOI 10.17487/RFC8445, July 2018,
<https://www.rfc-editor.org/info/rfc8445>.
[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. 50 change blocks. 
251 lines changed or deleted 328 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/