Subject: Re: [stir] [sipcore] New Version Notification for draft-ietf-sipcore-rejected-03.txt

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 4 Feb 2019 22:32:25 +0000

Looks good to me with a single comment:

"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."

The example confused me. How would the caller know that the intermediary is the terminating network? How would caller know which number to call? The use case of potentially not including Call-Info/jCard I had in mind was:

  *   Caller calls his own operator, which follows up the issue on his behalf
  *   There is a single, nation-wide number for the caller to contact (and that may be provided to caller party)

Thanks,
Tolga

1. Addressed /most/ of Tolga's nits. I decided to leave 'intermediary' as is. If the WG disagrees, I won't fall on my sword for it and will do a global substitution.

2. Fixed some unclear language Bhavik found when implementing the draft.

3. BTW, that means we have an open-source prototype at https://github.com/nagdab/608_Implementation

I think we're done. What do *you* think?

- Eric

>> On Feb 3, 2019, at 2:50 PM, [email-masked] wrote:
>>
>>
>> A new version of I-D, draft-ietf-sipcore-rejected-03.txt
>> has been successfully submitted by Eric W. Burger and posted to the
>> IETF repository.
>>
>> Name:                            draft-ietf-sipcore-rejected
>> Revision:        03
>> Title:                                A Session Initiation Protocol (SIP) Response Code for Rejected Calls
>> Document date:         2019-02-03
>> Group:                            sipcore
>> Pages:                             22
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-03.txt
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-03
>>
>> Abstract:
>>  This document defines the 608 (Rejected) SIP response code.  This
>>  response code enables calling parties to learn that an intermediary
>>  rejected their call attempt.  The call will not be answered.  As a
>>  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
>>  for the 608 response code is when the intermediary is an analytics
>>  engine.  In this case, the rejection is by a machine or other
>>  process.  This contrasts with the 607 (Unwanted) SIP response code,
>>  which a human at the target UAS indicated the call was not wanted.
>>  In some jurisdictions this distinction is important.  This document
>>  also defines the use of the Call-Info header in 608 responses to
>>  enable rejected callers to contact entities that blocked their calls
>>  in error.  This provides a remediation mechanism for legal callers
>>  that find their calls blocked.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>

-----------------------------------------------------------------------------------------------------------------------
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that
is confidential and/or proprietary for the sole use of the intended recipient.  Any review, disclosure, reliance or
distribution by others or forwarding without express permission is strictly prohibited.  If you are not the intended
recipient, please notify the sender immediately and then delete all copies, including any attachments.
-----------------------------------------------------------------------------------------------------------------------

---

From: Eric Burger <[email-masked]>
Date: Mon, 4 Feb 2019 18:52:32 -0500

I might have been thinking of the US situation where it is likely to be the terminating provider providing the blocking service. In the US, it’s trivial to look up the terminating provider from the number. For a carrier, its the LERG and NPAC. For a consumer, there are tons of free Web directories.

If there is a central phone number to call in a country for remediation, there’s no need for Call-Info, because presumably the callers will know the central phone number to call.

> On Feb 4, 2019, at 5:32 PM, Asveren, Tolga <[email-masked]> wrote:
> 
> 
> “Since the decision of whether to include Call-Info in the 608
>    outside the scope of this document.”
> 
> 
> Caller calls his own operator, which follows up the issue on his behalf
> There is a single, nation-wide number for the caller to contact (and that may be provided to caller party)
> 
> Thanks,
> Tolga
> 
> 
> 
> 1. Addressed /most/ of Tolga's nits. I decided to leave ‘intermediary’ as is. If the WG disagrees, I won’t fall on my sword for it and will do a global substitution.
> 
> 3. BTW, that means we have an open-source prototype at https://github.com/nagdab/608_Implementation <https://github.com/nagdab/608_Implementation>
> 
> I think we’re done. What do *you* think?
> 
> - Eric
> 
> >> On Feb 3, 2019, at 2:50 PM, [email-masked] <mailto:[email-masked]> wrote:
> >>
> >>
> >> URL:            https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-03.txt <https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-03.txt>
> >> Status:         https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/ <https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/>
> >> Htmlized:       https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03 <https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03>
> >> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected <https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected>
> >> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-03 <https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-03>
> >>
> >> Abstract:
> >> until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org/>.
> >>
> >> The IETF Secretariat
> >>
> >
> 
> 
> 
> Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
> _______________________________________________
> stir mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/stir <https://www.ietf.org/mailman/listinfo/stir>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 5 Feb 2019 08:39:39 +0000

“I might have been thinking of the US situation where it is likely to be the terminating provider providing the blocking service. In the US, it’s trivial to look up the terminating provider from the number. For a carrier, its the LERG and NPAC. For a consumer, there are tons of free Web directories.”
Yes, technically definitely possible. I just think of the practical aspects. It is even cumbersome to deal with one’s own operator let alone a 3rd party.

“If there is a central phone number to call in a country for remediation, there’s no need for Call-Info, because presumably the callers will know the central phone number to call.”
Exactly, and I would think this is not something unlikely.

Nonetheless, I think what matters is that it is spelled out clearly that Call-Info may be omitted. I just would prefer that the “central number” option is cited as well.

Thanks,
Tolga

From: Eric Burger <[email-masked]>
Sent: Monday, February 4, 2019 6:53 PM
To: Asveren, Tolga <[email-masked]>
Cc: [email-masked] Mail List <[email-masked]>
Subject: Re: [stir] [sipcore] New Version Notification for draft-ietf-sipcore-rejected-03.txt

On Feb 4, 2019, at 5:32 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Tolga

3. BTW, that means we have an open-source prototype at https://github.com/nagdab/608_Implementation<https://github.com/nagdab/608_Implementation>

- Eric

>> On Feb 3, 2019, at 2:50 PM, [email-masked]<mailto:[email-masked]> wrote:
>>
>>
>> URL:            https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-03.txt<https://www.ietf.org/internet-drafts/draft-ietf-sipcore-rejected-03.txt>
>> Status:         https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/<https://datatracker.ietf.org/doc/draft-ietf-sipcore-rejected/>
>> Htmlized:       https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03<https://tools.ietf.org/html/draft-ietf-sipcore-rejected-03>
>> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected<https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-rejected>
>> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-03<https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-rejected-03>
>>
>> Abstract:
>> until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.
>>
>> The IETF Secretariat
>>
>

________________________________
Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.
________________________________
_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir<https://www.ietf.org/mailman/listinfo/stir>

---

From: Eric Burger <[email-masked]>
Date: Tue, 5 Feb 2019 22:11:01 -0500

Is there any country in the world thinking of the approach of a central clearinghouse for robocall remediation? That sounds like a formula for a DoS target.

> On Feb 5, 2019, at 3:39 AM, Asveren, Tolga <[email-masked]> wrote:
> 
> From: Eric Burger <[email-masked] <mailto:[email-masked]>>
> To: Asveren, Tolga <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]> Mail List <[email-masked] <mailto:[email-masked]>>
> On Feb 4, 2019, at 5:32 PM, Asveren, Tolga <[email-masked] <mailto:[email-masked]>> wrote:
> 
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 7 Feb 2019 14:38:45 +0000

Would this attack vector be significantly worse than doing the same against the terminating carriers? There would be a handful of carriers in each country -for significant majority of calls-. So, DoS/few is still DoS IMHO.
And in general, there is lots of mischief one can do with SIP responses anyhow. The -more or less- remedy would be using a new claim consisting of origid/attest for *all* messages so that they can be traced.

As far as draft-ietf-sipcore-rejected is considered, I am fine with whatever you decide -including keeping the existing text intact-- as long as not including Call-Info is allowed.

So, overall, I think this draft is ready to move forward.

Thanks,
Tolga

Sent: Tuesday, February 5, 2019 10:11 PM

On Feb 5, 2019, at 3:39 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Tolga

From: Eric Burger <[email-masked]<mailto:[email-masked]>>
Sent: Monday, February 4, 2019 6:53 PM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> Mail List <[email-masked]<mailto:[email-masked]>>
Subject: Re: [stir] [sipcore] New Version Notification for draft-ietf-sipcore-rejected-03.txt

Thanks,
Tolga

- Eric