Re: [stir] New draft draft-rosenberg-stir-callback-00

["Gorman, Pierce A [CTO]" <[e-mail]>]

SBCs do not terminate calls.  And, experience has shown some SIP stacks do not support RFC 3262, even if the SBC did.


From: David Frankel [mailto:[e-mail]]
Sent: Monday, March 05, 2018 10:20 AM
To: 'Cullen Jennings (fluffy)' <[e-mail]>
Cc: 'Jonathan Rosenberg' <[e-mail]>; [e-mail]
Subject: Re: [stir] New draft draft-rosenberg-stir-callback-00

Thanks for your response, Cullen.

I’ll try to address your questions and comments at the top here, rather than burying them below.

Regarding specifics of the misbehaving SBCs: I’m not comfortable identifying them here, but I can try to reach out to them to see if they want to engage directly in this discussion (or if they can give me any information to relay as to why they are non-conforming). I can tell you that they are all licensed CLECs (ranging from tiny to very large). From my parsing of the 200-OK they send back to me, at least some are using commercial SBCs; in one case, it looks like that SBC provider is now out of business. That’s not uncommon in this domain.

I can think of a few possibilities as to why these SBCs are behaving as they are: (1) The manufacturer didn’t adhere to the SIP RFCs, either on purpose or due to carelessness; (2) The provider mis-configured the SBC in error; (3) The default configuration for the SBC doesn’t adhere to the RFCs; (4) The provider encountered some issue in the past and purposefully altered the configuration, and this is the desired result or side-effect; (5) There’s a bug. I’ve encountered all of these over the years.

Certainly some providers will be motivated and cooperative in fixing problems and implementing new extensions. Others will be recalcitrant. I have said to providers about other non-compliant situations: “Read the RFC. What don’t you understand about SHALL or MUST?” And they respond “What don’t YOU understand when we tell you: We don’t support that aspect of the RFC.” With respect to STIR-Callback specifically, I can imagine that for our example, where B is sending a verify invite to A via X and Y, Alice’s phone will ring improperly, but A will point the finger at X (or Y) for dropping the REQUIRE header. Since Alice is a customer of A and not X, your notion of “the economics of customer satisfaction and retention” won’t apply.

I agree with you: these same factors will definitely play into 8224 deployment and the propagation of the IDENTITY header. I believe that the team will be successful with some relatively rapid initial in-the-field demonstrations. But if your objective is to make a serious dent in the robocalling epidemic, that requires much higher penetration because you’re battling a reactive, clever enemy force. Given everything that has to change for 8224, that is going to take many years.

Herding the many hundreds of US telecom providers that it takes to get to critical mass is a huge hurdle when we have to write new software and then get it deployed and configured. The multi-hop nature of our call network means we fail on a weak link. Worse, given the robustness of SS7 and the huge sunk investment, it’s going to take quite some time for it to be displaced to a level of insignificance. We’ll live in a two-protocol world for the foreseeable future.

What to do in the meantime? I continue to be optimistic about leveraging BILLING TELEPHONE NUMBER – a field that predates even Caller-ID. BTN is in SS7 as Charge Number, and interworks to SIP P-Charge-Info. In earlier days, BTN was important for billing and jurisdiction; things that providers HAD to pay attention to. Thus, it IS supported in virtually all installed network elements. In my experience, it usually gets propagated by intermediaries.

By using BTN to identify call originators, or at least originating providers, we can throw a much brighter light on the source of our robocall problems, instead of continuing to flounder in the dark. That can be accomplished by regulation, mandating that providers insert the BTN and not permit customers to spoof it. This approach won’t work 100% of the time, but it can make a huge bite today while we wait for more sophisticated solutions to get to critical mass. I’m interested in your thoughts here.

Many are quick to point out that robocalls can originate from overseas, where our mandates are ineffective. However, every call to a USA PSTN number comes through some USA-regulated originating provider, and those providers have commercial agreements with whoever is sending them the calls. So there is a mechanism to push back on the ultimate source. There’s a fair amount of evidence that at least today, the majority of robocalls come from a relatively small number (dozens) of sources, so our first priority should be to find and stop those.

David

David Frankel
ZipDX® LLC
Monte Sereno, CA USA
Tel: 1-800-FRANKEL (1-800-372-6535)

From: stir <[e-mail]<mailto:[e-mail]>> On Behalf Of Cullen Jennings (fluffy)
Sent: Sunday, March 4, 2018 5:03 PM
To: David Frankel <[e-mail]<mailto:[e-mail]>>
Cc: Jonathan Rosenberg <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] New draft draft-rosenberg-stir-callback-00



On Mar 4, 2018, at 12:50 AM, David Frankel <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jonathan and Cullen –

I read the draft with interest and wonder if you can clarify a few things for me. My understanding of SIP nuances is limited, so I may be overlooking some obvious things here. At the same time, I’m trying to be pragmatic about how things work in the “real world” vs. the world as defined by the specs.

So my questions / comments are:

A) I see in section 3 references to SUPPORTED and REQUIRE header fields that include “stir-callback”. Then in sub-part 1 of section 3, in the call diagram I see references to SUPPORTED and REQUIRE headers that say “stir-verify”.  (Note, btw, that there are two sub-parts 1 in section 3; I think they are supposed to be numbered 1, 2, 3 instead of 1, 1, 2.) There are further references in the document to “stir-verify”. Then in section 8.1, there are references to a “sip-verify” Option Tag.

So my question is: are “stir-callback”, “stir-verify” and “sip-verify” all meant to be the same string, and perhaps the exact value evolved during development of the document? Or are there really two or three different option-tags involved here? Or am I missing how these three different values are actually applied?


We probably just messed up some cut and paste as we changed names.

B) In the “real world”, a PSTN call from Bob (tel:1, served by Provider B), to Alice (tel:2<tel:1>, served by Provider A) is often completed by B sending the call to transit provider X, which, even in an end-to-end SIP connection, will re-initiate the call and send it to provider Y, which then re-initiates it and sends it to terminating Provider A. (Note that the call path from B to A typically does not necessarily follow the reverse path of a call from A to B.)

So in order to propagate properly from origination to termination, the “verifying INVITE” proposed in section 3, containing the REQUIRE: stir-callback header, will need to first be processed by Provider X. As I understand it, X will need to be capable of recognizing the new REQUIRE header and knowing that it needs to propagate the call onward (NOT reject it due to lack of support for stir-callback), and will need to send the call to Y with the new REQUIRE header included. AND it will also need to know that it needs to propagate the VERIFY-CALL header as well.

Y will receive this INVITE, and it too will need to know that it needs to accept this invite and propagate it onward with the REQUIRE and VERIFY-CALL headers.

Since stir-callback is not today a defined option, if X and Y were conforming to the SIP RFC, they would today reject this INVITE. So does this mean that your STIR-Callback approach will necessitate updates of currently-conforming UA’s acting in the transit role to now provide support for this new type of INVITE?

Finally, if and when the verification INVITE gets to A, and as your document explains, A will have to be smart enough to process the verify request and send the appropriate response. That support is noted in your document; I’m wondering if you also need to document the kind of support that will be required from intermediate providers, and note the importance of A being RFC-compliant with respect to REQUIRE headers it does not understand.

Yes, you are right the intermediate providers SBCs would need to be configured to support that require header. This is certainly a deployment issue but I’m not sure I see it as much different from the same SBCs needing to be configured to 8224 Identity header. Thoughts ?


C) At the end of section 3 you note: “The presence of the Require header field in the verifying INVITE is critical to the operation of the solution.  It prevents the verifying INVITE from actually ringing a real phone, which would be quite annoying.” This is my biggest concern.

If the new REQUIRE header gets dropped somewhere along the way, the INVITE will look “normal”, so won’t Provider A ring Alice’s phone? Or, if A is not RFC-compliant and ignores the REQUIRE header, Alice’s phone will ring. (And of course if the call originator was spoofing the number, and in fact Bob’s verification INVITE went to the real owner of the number, served by provider C, C would have to be RFC-compliant in this regard or the real number owner’s phone would ring.)

I am nervous that in today’s real world deployments, your approach is fragile because it is dependent on the various UA’s in the call path diligently following the SIP RFC.

I made a few test calls acting like I was Bob’s UA, having received an INVITE from A that I want to verify. So I sent an INVITE back towards A, inserting the REQUIRE: stir-callback header in my mock “verification” INVITE; I sent these calls through various real-world termination providers.

In a couple of cases, I got back 420 Bad Extension responses. That’s good and bad; the good news is that it tells me that those particular UA’s ARE RFC compliant in this respect. They don’t understand a REQUIREd option so they are necessarily rejecting the call. On the other hand, it points out that if these UA’s are acting as intermediate providers (which, in these cases, they are), they will need to be updated to accept and pass the stir-callback related headers even though they are just providing a transit function and even though they are not assuming any responsibility for verification.

In my other test cases, the destination phone rang even though this was supposed to be a “verification” INVITE. This tells me, I think, that at least the first UA (X, in my explanation above) in the verification call path is non-RFC-complaint, and that downstream UA’s are either also non-compliant, or that the REQUIRE header got dropped along the way.

I am nervous about the extent to which deployed UA’s are non-RFC-compliant with respect to the REQUIRE header, and how that could undermine deployability of this solution. Maybe you intended that the solution only apply when A and B are directly connected and there are no intermediate providers. But I’m concerned that’s only a small fraction of “real world” calls today.


First let me say that is awesome you just went and tried this. I love real world data. Some of the version of Asterisk I have seen configured that way but sort of surprised if people are using ACME or Cisco SBCs that way. I certainly don’t have any desire to embarrass any particular SP about their SIP deployment but would you be willing to share what providers did this such that we might try and track down why they did it - that might help decide how much of an issue it is?


I am interested in your thoughts on these items, and on getting me back on track if I’ve misunderstood aspects of the proposal.


I think you have understood the gist of the proposal and perhaps we have some tweaks to make. I agree with your high level points of there are intermediaries in the call we care about and that if any server along the chain is non compliant with require, it does not work well. Perhaps we can think of ways to mitigate that but not obvious how.

Now that we have 8824 out the door, I’m more trying out ideas to see what might work to help reduce SPAM and I share some of your concerns about this but not sure what’s better for deployment.

However, any in band STIR solution is going to require the service providers to test and support it. I would not be surprised to find that any SBC configured to ignore the Require header is also pretty unlike to pass the Identity header.  For a long time, I have seen many things blocked at IETF from by the “SBC won’t support that” argument but in this particular case it is a bit different. If some carrier has all of it customers getting an irritating call back call ever time they dial a new number, I’m sure the economics of customer satisfaction and retention will cause that carrier to change the configuration of their SBC to not ignore the Require header.

I am worried about this and the rest of STIR when the interconnect between the carriers is SS7.



David

David Frankel
ZipDX® LLC
Monte Sereno, CA USA
Tel: 1-800-FRANKEL (1-800-372-6535)

From: stir <[e-mail]<mailto:[e-mail]>> On Behalf Of Jonathan Rosenberg
Sent: Thursday, March 1, 2018 6:15 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [stir] New draft draft-rosenberg-stir-callback-00

Hey all - been a while :)
Cullen and I wrote up a concept for using STIR with self-signed or domain based certs, and then handling number validation with an in-band callback. We think its a promising approach to accelerate STIR deployments, since it allows them to happen without the cert infrastructure being in place.

https://www.ietf.org/id/draft-rosenberg-stir-callback-00.txt
Comments welcome.
-Jonathan R.

--
Jonathan Rosenberg, Ph.D.
[e-mail]<mailto:[e-mail]>
http://www.jdrosen.net<http://www.jdrosen.net/>
_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir


________________________________

This e-mail may contain Sprint proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.