< draft-ietf-sipcore-rejected-02.txt   draft-ietf-sipcore-rejected-03.txt >
SIPCORE E. Burger SIPCORE E. Burger
Internet-Draft Georgetown University Internet-Draft Georgetown University
Intended status: Standards Track December 28, 2018 Intended status: Standards Track B. Nagda
Expires: July 1, 2019 Expires: August 7, 2019 Massachusetts Institute of Technology
February 3, 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-02 draft-ietf-sipcore-rejected-03
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 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
defines the use of the Call-Info header in 608 responses to enable also defines the use of the Call-Info header in 608 responses to
rejected callers to contact entities that blocked their calls in enable rejected callers to contact entities that blocked their calls
error. 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 July 1, 2019. This Internet-Draft will expire on August 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 7 3.1. Intermediary Operation . . . . . . . . . . . . . . . . . 8
3.2. jCard Construction . . . . . . . . . . . . . . . . . . . 8 3.2. jCard Construction . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . 8 3.2.3. JWS Signature . . . . . . . . . . . . . . . . . . . . 9
3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 8 3.3. UAC Operation . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 9 3.4. Legacy Interoperation . . . . . . . . . . . . . . . . . . 9
3.5. Announcement Requirements . . . . . . . . . . . . . . . . 10 3.5. Announcement Requirements . . . . . . . . . . . . . . . . 10
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Full Exchange . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 14 4.2. Web Site jCard . . . . . . . . . . . . . . . . . . . . . 15
4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 14 4.3. Multi-modal jCard . . . . . . . . . . . . . . . . . . . . 15
4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 15 4.4. Legacy Interoperability . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 16 5.1. SIP Response Code . . . . . . . . . . . . . . . . . . . . 17
5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 16 5.2. SIP Feature-Capability Indicator . . . . . . . . . . . . 17
5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 17 5.3. JSON Web Token Claim . . . . . . . . . . . . . . . . . . 18
5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 17 5.4. Call-Info Purpose . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1. Normative References . . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20 8.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
The IETF has been addressing numerous issues surrounding how to The IETF has been addressing numerous issues surrounding how to
handle unwanted and, depending on the jurisdiction, illegal calls handle unwanted and, depending on the jurisdiction, illegal calls
[RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN] [RFC5039]. Technologies such as STIR [RFC7340] and SHAKEN [SHAKEN]
address cryptographic signing and attestation, respectively, of address 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
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 an intermediary rejected their call. As calling parties to learn that an intermediary rejected their call.
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, calls, even if unwanted by the user, may not
be blocked unless there is an explicit user request. Moreover, users be blocked unless there is an explicit user request. Moreover, users
may misidentify the nature of a caller. For example, a legitimate may misidentify the nature of a caller.
caller may call a user who finds the call to be unwanted. However,
instead of marking the call as unwanted, the user may mark the call For example, a legitimate caller may call a user who finds the call
as illegal. With that information, an analytics engine may determine to be unwanted. However, instead of marking the call as unwanted,
that all calls from that source should be blocked. However, in some the user may mark the call as illegal. With that information, an
jurisdictions blocking calls from that source for other users may not analytics engine may determine that all calls from that source should
be legal. Likewise, one can envision jurisdictions that allow an be blocked. However, in some jurisdictions blocking calls from that
operator to block such calls, but only if there is a remediation source for other users may not be legal. Likewise, one can envision
mechanism in place to address false positives. jurisdictions that allow an operator to block such calls, but only if
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. As well, in many receive calls from anyone, even if wanted. In many jurisdictions,
jurisdictions, providing false signaling is 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 an blocked calls. Specifically, this code informs the UAC that an
intermediary blocked the call and provide a redress mechanism, intermediary blocked the call and provides a redress mechanism that
specifically how to contact the operator of the intermediary. allows callers to contact the operator of the intermediary.
In the call handling ecosystem, users can explicitly reject a call or In the current call handling ecosystem, users can explicitly reject a
later mark a call as being unwanted by issuing a 607 SIP response call or later mark a call as being unwanted by issuing a 607 SIP
code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the operation response code (Unwanted) [RFC8197]. Figure 1 and Figure 2 shows the
of the 607 SIP response code. The UAS indicates the call was operation of the 607 SIP response code. The UAS indicates the call
unwanted. As RFC8197 explains, not only does the called party desire was unwanted. As RFC8197 explains, not only does the called party
to reject that call, they can let their proxy know they consider desire to reject that call, they can let their proxy know that they
future calls from that source unwanted. Upon receipt of the 607 consider future calls from that source unwanted. Upon receipt of the
response from the UAS, the proxy may send call information to a call 607 response from the UAS, the proxy may send call information to a
analytics engine. For various reasons described in RFC8197, if a call analytics engine. For various reasons described in RFC8197, if
network operator receives multiple reports of unwanted calls, that a network operator receives multiple reports of unwanted calls, that
may indicate the entity placing the calls is likely to be a source of may indicate that the entity placing the calls is likely to be a
unwanted calls for many people. As such, other users of the service source of unwanted calls for many people. As such, other customers
provider's service may wish the service provider to automatically of the service provider may want the service provider to
reject calls on their behalf based on that and other analytics. 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 UAC, the calling UAC or intervening proxies
will also learn the user is not interested in receiving calls from will also learn the user is not interested in receiving calls from
that sender. that sender.
+-----------+ +-----------+
| Call | | Call |
| Analytics | | Analytics |
| Engine | | Engine |
skipping to change at page 4, line 32 skipping to change at page 4, line 42
the user. Moreover, if a legitimate caller believes the user is the user. Moreover, if a legitimate caller believes the user is
rejecting their calls in error, they can use other channels to rejecting their calls in error, they can use other channels to
contact the user. For example, if a pharmacy calls a user to let contact the user. For example, if a pharmacy calls a user to let
them know their prescription is available for pickup and the user them know their prescription is available for pickup and the user
mistakenly thinks the call is unwanted and issues a 607 response mistakenly thinks the call is unwanted and issues a 607 response
code, the pharmacy, having an existing relationship with the code, the pharmacy, having an existing relationship with the
customer, can send the user an email or push a note to the pharmacist customer, can send the user an email or push a note to the pharmacist
to ask the customer to consider not rejecting their calls in the to ask the customer to consider not rejecting their calls in the
future. future.
Moreover, many systems that allow the user to mark the call unwanted Many systems that allow the user to mark the call unwanted (e.g.,
(e.g., with the 607 response code) also allow the user to change with the 607 response code) also allow the user to change their mind
their mind and unmark such calls. This is relatively easy to and unmark such calls. This mechanism is relatively easy to
implement as the user usually has a direct relationship with the implement as the user usually has a direct relationship with the
provider of the blocking service. service provider that is blocking calls.
However, things get more complicated if an intermediary, such as a However, things become more complicated if an intermediary, such as a
third-party provider of call management services that classify calls third-party provider of call management services that classifies
based on the relative likelihood the call is unwanted, misidentifies calls based on the relative likelihood that the call is unwanted,
the call as unwanted. Figure 3 shows this case. Note the UAS misidentifies the call as unwanted. Figure 3 shows this case. Note
typically does not receive an INVITE as the proxy rejects the call on that the UAS typically does not receive an INVITE since the called
behalf of the user. In this situation, it would be beneficial for party proxy rejects the call on behalf of the user. In this
the caller to be able to learn who rejected the call, so they might situation, it would be beneficial for the caller to learn who
be able to correct the misidentification. rejected the call, so they can correct the misidentification.
+--------+ +-----------+ +--------+ +-----------+
| Called | | Call | | Called | | Call |
+-----+ | Party | | Analytics | +-----+ +-----+ | Party | | Analytics | +-----+
| UAC | | Proxy | | Engine | | UAS | | UAC | | Proxy | | Engine | | UAS |
+-----+ +--------+ +-----------+ +-----+ +-----+ +--------+ +-----------+ +-----+
| INVITE | | | | INVITE | | |
| --------------> | INVITE | | | --------------> | INVITE | |
| | ------------------------------> | | | ------------------------------> |
| | | | | | | |
skipping to change at page 5, line 49 skipping to change at page 6, line 9
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 network elements downstream
from the intermediary might interpret the 607 as a user (human) from the intermediary might interpret the 607 as a user (human)
marking the call as unwanted, as opposed to a statistical, machine marking the call as unwanted, as opposed to a statistical, machine
learning, vulnerable to the base rate fallacy [BaseRate] algorithm learning, vulnerable to the base rate fallacy [BaseRate] algorithm
rejecting the call. In other words, those downstream entities should rejecting the call. In other words, those downstream entities should
not be relying on another entity 'deciding' the call is unwanted. By not be relying on another entity 'deciding' the call is unwanted. By
distinguishing between a (human) user rejection and an intermediary's distinguishing between a (human) user rejection and an intermediary
statistical rejection, a downstream network element that sees a 607 engine's statistical rejection, a downstream network element that
response code can weight it as a human rejection in its call sees a 607 response code can weight it as a human rejection in its
analytics. 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.
One might ask why we cannot use the same mechanism an analytics One might ask why we cannot use the same mechanism an analytics
service provider offers their customers that lets them correct a call service provider offers their customers that lets them correct a call
blocked in error? The reason is whilst 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 while a mechanism for indicating an intermediary rejected a call that also
providing contact information for the operator of the intermediary provides contact information for the operator of that intermediary,
that provides call rejection services to the called party, without without exposing the target user's contact information.
exposing the target user's contact information.
The protocol described in this document uses existing IETF protocol The protocol described in this document uses existing IETF protocol
mechanisms for specifying the redress mechanism. Specifically, we mechanisms for specifying the redress mechanism. In the SIP header
use jCard [RFC7095] encoding of the redress address. For integrity passed back to the UAC, we send additional information specifying a
protection, we sign the redress address. Conveniently, we use jCard redress address. We choose to encode the redress address using jCard
rather than vCard [RFC6350] as we have a standard marshaling [RFC7095]. Conveniently, we use jCard rather than vCard [RFC6350] as
mechanism for creating a canonical representation of a JSON [RFC8259] we have a standard marshaling mechanism for creating a canonical
object, such as a jCard, and a standard presentation format for such representation of a JSON [RFC8259] object, such as a jCard, and a
an object, namely JWS [RFC7515]. The SIP community is familiar with standard presentation format for such an object, namely JWS
this concept as it is the mechanism used by STIR [RFC8224]. [RFC7515]. The SIP community is familiar with this concept as it is
the mechanism used by STIR [RFC8224].
The jCard encoding might seem unnecessary at first, but it is
essential to preventing potential network attacks. Suppose, for
example, that the redress address was simply passed as a header
value. One can imagine an adverse agent that maliciously spoofs a
608 response with the same redress address to a large number of
active callers, who may then all send redress requests to the
specified address (the basis for a denial-of-service attack). The
process would occur as follows: (1) a malicious agent senses INVITE
requests from a variety UACs and (2) spoofs 608 responses with an
unsigned redress address before the intended receivers can respond,
causing (3) the UACs to all contact the redress address at once. The
jCard encoding allows the UAC to verify the blocking intermediary's
identity before contacting the redress address. This guards against
a malicious agent spoofing 608 responses, preventing the denial-of-
service attack. Thus if the jCard address is unreachable or
undecipherable, either (1) a malicious agent is lying about the jCard
or (2) the redress mechanism is misconfigured.
2. Terminology 2. Terminology
This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL", This document uses the terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only "OPTIONAL" as described in BCP14 [RFC2119][RFC8174] when, and only
when, they appear in all capitals, as shown here. when, they appear in all capitals, as shown here.
As a matter of principle, this document uses the term "UNLESS" to As a matter of principle, this document uses the term "UNLESS" to
distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD" distinguish when a "SHOULD" means "MAY". Otherwise, the "SHOULD"
means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a. means "MUST". Without UNLESS, SHOULD is meaningless. A.k.a.
Burger's Law of Protocol Meaningness. Burger's Law of Protocol Meaningless Terms.
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 17, line 40 skipping to change at page 18, line 40
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 of whom they are sending
the 608 response to. There is a risk that a truly malicious caller the 608 response. There is a risk that a truly malicious caller is
is being rejected. This raises two issues. The first is the caller, being rejected. This raises two issues. The first is the caller,
being alerted their call is being automatically rejected, may change now alerted that the call is being automatically rejected, may change
their call behavior to defeat call blocking systems. The second, and their call behavior to defeat call blocking systems. The second, and
more significant risk, is that by providing a contact 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].
skipping to change at page 18, line 39 skipping to change at page 19, line 39
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
response is a matter of policy, one thing to consider is whether a
legitimate caller can ascertain whom to contact without such
information being included in the 608. For example, in some
jurisdictions, if the terminating service provider is the
intermediary, the caller can lookup who the terminating service
provider is based on the routing information for the dialled number.
As such, the Call-Info jCard could be redundant information.
However, the factors going into a particular service provider's or
jourisdiction's choice of whether or not to include Call-Info is
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. addition, Tolga came up with the jCard attack.
Finally, Bhavik Nagda provided clarifying edits as well and more
especially wrote and tested an implementation of the 608 response
code in Kamailio. Code is available at <https://github.com/
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,
skipping to change at page 21, line 15 skipping to change at page 22, line 35
[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.
Author's Address Authors' Addresses
Eric W. Burger Eric W. Burger
Georgetown University Georgetown University
37th & O St, NW 37th & O St, NW
Washington, DC 20057 Washington, DC 20057
USA USA
Email: eburger@standardstrack.com Email: eburger@standardstrack.com
Bhavik Nagda
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139
USA
Email: nagdab@gmail.com
 End of changes. 30 change blocks. 
98 lines changed or deleted 136 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/