Re: [sipcore] I-D Action: draft-ietf-sipcore-rejected-02.txt

["Asveren, Tolga" <[e-mail]>]

Hi Eric,

New wording you suggested regarding the need/use of 608 sounds better to me.

For “intermediary” maybe “SIP intermediary”? Or would that be opening up a can of worms where this term itself needs to be defined? I would be fine either way (keeping it as is or using “SIP intermediary”).

For the need of “semantics of 608 + jCard being atomic”: Just based on history, yes I think you are being too strict :-)   Raising the bar high usually does not provide best results. The “default text” could mention the name Originating SP name directly and I guess that would be intelligible to any end user. I think this text is displayed not based on jCard multipart/alternate with a text version but should be a “native” capability of UAC itself IMHO. Otherwise, it would beat the purpose of providing a fallback for “lazy” implementations and infrastructure/deployment/management issues with public key being available/accessible. Having said that, it of course is preferable if jCard is supported, this would be only a fallback.

Thanks,
Tolga

From: Eric Burger <[e-mail]>
Sent: Wednesday, January 2, 2019 12:44 PM
To: Asveren, Tolga <[e-mail]>
Cc: [e-mail]
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-rejected-02.txt

Tolga - As always, thanks for your review!
Thoughts inline.

On Dec 30, 2018, at 9:26 AM, Asveren, Tolga <[e-mail]<mailto:[e-mail]>> wrote:

Looks good to me with a few comments:

i-
1. Introduction

As
   described below, we need a distinct indicator to differentiate
   between a user rejection and an intermediary's rejection of a call.
   In some jurisdictions, calls, even if unwanted by the user, may not
   be blocked unless there is an explicit user request.
[TOLGA] I agree with the intend but the wording could be improved IMHO to clarify that 607 is not an “explicit user request”. Maybe by just adding “by other means” to the end of the last sentence?

607 is explicit user request, vs. 608 which is only a guess as to the user’s desire. In many jurisdictions, carriers have an obligation to complete (not block) calls, unless they are obviously illegal or the user explicitly requests blocking the call.

What if we put this into active voice?

This document describes a new SIP response code, 608, which allows calling parties to learn an intermediary rejected their call. As described below, we need a distinct indicator to differentiate between a user rejection and an intermediary's rejection of a call. In some jurisdictions, an intermediary can only block calls calls if there is an explicit user request. By giving legitimate callers the ability to correct blocks in error, some jurisdictions may decide to allow for intermediaries to block calls with implicit user request.



 Specifically, this code informs the UAC an

   intermediary blocked the call and provide a redress mechanism,

   specifically how to contact the operator of the intermediary.
[TOLGA] Couldn’t blocking be done also by the terminating SP and 608 still would be applicable AFAICS. “Intermediary” may cause confusion. It could be an idea to replace it with “an operator on the call path including intermediary operators”.
 However, things get more complicated if an intermediary, such as a

   third-party provider of call management services that classify calls

   based on the relative likelihood the call is unwanted, misidentifies

   the call as unwanted.
[TOLGA] Similar comment as the previous one.

I was thinking ‘intermediary’ in the SIP sense. I was struggling what to call it. Technically, it’s just the UAS, because that’s where the INVITE terminates. However, that is too easy to confuse with the UAS of the INVITE target. I didn’t want to use ‘Proxy’ or B2BUA, because who knows if that’s what it will be.

Do you (or anyone else) have a better term?



 ii-
3.3.  UAC Operation

A UAC conforming to this specification MUST include the sip.608

   feature capability tag in the INVITE request.
[TOLGA]What about other requests?
What about a registering end point indicating support in REGISTER Contact? I think the idea is that it still adds sip.608 to the request as well. It could be good to add a clarification about this case.
I think sip.608 means support for jCard as well. That IMHO is a taller order than just supporting a new response code. IMHO it could be good that always “Your calling number is blocked. Please contact the blocking organization based on the following information. Please contact your Originating SP if you don’t see any additional information” is displayed on the UAC upon receipt of 608.

Well… If you write code to explicitly deal with sip.608, as opposed to just generically handling 6xx), you get to support a JWT encoding of a jCard, including all the PKI support that implies. I.e., the jCard part is the least of your worries. Saying “contact your Originating SP” will be as useful as “Configure your STUN server [to electrocute yourself].” I.e., that will be meaningless information to Joe Average User. That’s also why I didn’t bother to include a multipart/alternate with a text version of the jCard. Either you understand sip.608 or you don’t.

Am I being too strict here?


 iii-
3.4.  Legacy Interoperation
[TOLGA] A malicious UAC may drain Operator announcement resources by placing many calls with a blocked calling-Id and not signaling sip.608. This can be remedied by playing announcement only once for each blocked calling-Id, or for every nth call, or only when announcement resources are idle. Granted, this could cause some hiccups if the same calling-Id is used by many UACs but still worth mentioning IMHO.

I like the idea. If it is a legal caller, then it’s likely a call center, and one announcement should be enough. If it is a spammer reusing the same calling-id, then who cares if they don’t get the message?




Thanks,
Tolga



[Cross-posted to IP-NNI, NNI, and STIR lists; please keep any discussion on the SIPCORE list]


What do we have here? This version is resistant to replay attacks. It also lets us trace jCards, if we wish.

I think it’s done, but I’m sure there are glaring holes that could be filled.

Please review.

Thanks, and Happy New Year.


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